Whirly Fizzle

Alice, can you try this please and let us know if it works. Drop a copy of msvcr100.dll into your Firestorm 64bit install folder. You can grab the msvcr100.dll here: https://dl.dropboxusercontent.com/u/42703858/msvcr100.dll Thanks!

I didn't answer because I'm not 100% sure how this special box was created. But this is what I think happened. There was a bug at the beginning of December (now fixed) that caused certain objects to not get autoreturned because they behaved as if they were selcted/sat upon when they wern't - this bug is discussed briefly here Any objects that were "infected" by this bug will now (since the fix) exhibit behaviour like Anne-Marie's special box, in that they will die after crossing a region if they have no sitter. If you want an accurate answer for why this box was "special", compell yourself over to the deploy thread and ask Maestro :smileyindifferent:

Oh cross post. Glad you found the culpret. Yes, that collar is one of the known causes of this crash.

Ramona, If you can file a JIRA issue on the Firestorm JIRA, reproduce this crash and attach your crash logs to the JIRA issue, we can quickly see if you are having the crash I think you are having. This Page tells you how to file a Firestorm JIRA and where to find your crash logs. After you have reproduced this edit crash, grab the whole logs folder and zip it up, before you relaunch the viewer.

It sounds like you are suffering from this crash FIRE-10910 - [bUG-3095] [MAINT-2876] [CRASH] Right click rigged mesh -> freeze/crash - Octree insertion failed, starting over from root! This crash affects all viewers and only happens with certain rigged high poly meshes. It also usually only happens when you are up at 2000+m strangely. If you click anywhere inside that meshes octree, the viewer will freeze in an infinate loop & you'll have to force quit. I'm afraid theres no known workaround apart from to find which piece of rigged mesh you are wearing is the culpret and take it off.

The viewer crashing intsead of failing gracefully when attempting to upload a corrupted dae is a known bug, FIRE-12763 - [bUG-4961] [MAINT-3661] Crash to desktop while attempting to upload a corrupted mesh after selecting file from open window - load_face_from_dom_triangles BUG-4961 - Viewer crashes when attempting to upload a corrupted dae instead of failing gracefully. Hopefully BUG-4961 will be visible one the JIRA has reopened. The Firestorm issue is the same bug though.

Maestro explained what the problem was on the Deploy Thread

Cassandra Kestrel wrote: Edit: Now she's doing something else weird... one of her stations is rezzing a huge cube (not phantom) in the middle of the road and then sliding it over. Over and over again. That box was part of a bug repro set up for the Lindens to see. You probably also saw boxes owned by myself there testing this bug :smileywink: This particular bug that was being tested is now fixed on Bluesteel and LeTigre - "Fixed a bug in which certain objects had incorrect status when crossing between regions" So, nothing sinister, just bug hunting.

I don't know if this has changed since (I havnt tested for a while), but a short while before christmas there was a change made that meant that if one of your avatars was added to an estate ban list, then your alts would also not be able to access that estate. Your actual banned avatar who's name was on the estate ban list would receive the standard "You are banned from this region" message when trying to access regions on that estate, whereas your alts would receive a "You do not have access to this region" message (as far as I can remember - the message didnt explicitly say you were banned for the alts anyway). I stumbled on this one by accident because I had an alt banned from my estate for testing something, and suddenly some of my other alts couldnt gain access to my region.

Trinity Nizna wrote: Firestorm hasnt released their updated veiwer for fitted mesh yet.... [0:51:07] The next release of Firestorm will be out around March 9th – possibly a little before, possibly after. Some of what should be in it includes: that what is says on they info page here link.. (read it over) https://modemworld.wordpress.com/2014/02/17/feb-15th-firestorm-qa-video-and-transcript-next-release-and-news/ This crash has nothing to do with fitted mesh. Its an out of bounds crash caused by certain meshes and this crash existed before fitted mesh was on the grid. This crash was fixed in the materials code. So, if you update to Firestorm 4.5.1, which has the materials code, you will no longer crash with Iki's mesh.

Pyro, if you update to the 4.5.1 version of Firestorm, you will not be crashed by Iki's mesh. Download links are here: http://wiki.phoenixviewer.com/downloads

Also to note, each time this has happened to me, there has not been any scheduled/unscheduled maintenance ongoing on the grid status page. I made sure to check back a few hours after I could login again and there were still no posts about maintenance at those times.

Yeah, I've been seeing this problem recently too and so have some friends. Its very sporadic but it happens regularly enough to be annoying :smileyfrustrated: The login screen just remains stuck forever showing "Logging in....". When I have had this happen, it appears to be account specific. I can hop on an alt and login with no problems at all but trying to log the affected avatar in on either Firestorm or the official Linden lab viewer or even the old Phoenix viewer or SL 1.23 viewer fails in the same way. The last time I had this happen I purged my cache and settings folders for both the official viewer and Firestorm, which did not help at all, though I am fairly sure this is a prolem at LL's end, it was worth a try. Each time its happened, its only lasted a couple of hours max. I suspect something is going wrong with the login server for certain accounts when this happens. If I look at my logs when its stuck at "Logging in....", the logs just sit there stuck at this line.... INFO: newview/llxmlrpclistener.cpp(327) : Poller::Poller: login_to_simulator request sent to https://login.agni.lindenlab.com/cgi-bin/login.cgi If I run the viewer through a debugger and attempt to login the affected account, wait for it to get stuck at logging in and then break to get a stack, I get... 0:000> kV ntdll!KiFastSystemCallRet kernel32!Sleep+0xf Firestorm_Beta!ms_sleep+0xd (FPO: [Non-Fpo]) (CONV: cdecl) [c:\fs\build_fs_windows_firestorm_4_5_1\build\indra\llcommon\lltimer.cpp @ 80] Firestorm_Beta!LLAppViewer::mainLoop+0xf38 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\fs\build_fs_windows_firestorm_4_5_1\build\indra\newview\llappviewer.cpp @ 1651] Firestorm_Beta!WinMain+0x1f2 (FPO: [Non-Fpo]) (CONV: stdcall) [c:\fs\build_fs_windows_firestorm_4_5_1\build\indra\newview\llappviewerwin32.cpp @ 304] Firestorm_Beta!__tmainCRTStartup+0x150 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 547] kernel32!BaseThreadInitThunk+0x12 ntdll!RtlInitializeExceptionChain+0x63 ntdll!RtlInitializeExceptionChain+0x36

Iki sent me her mesh for testing and I can confirm that any viewer that does not have the Materials feature will crash as soon as that mesh is rendered. Those getting this crash on Firestorm 4.4.2 should update to the 4.5.1 beta.

Merry Christmas to you too Rudolf :heart:

Prokofy Neva wrote: Where do you find the chat logs and other avatar files for Second Life in Windows 8? You know that folder that is users/name/appdata/roaming etc. Can't find it for the life of me. Make sure hidden files and folders are set to show first. See http://www.bleepingcomputer.com/tutorials/show-hidden-files-in-windows-8/ Then browse to C:\Users\[uSERNAME]\AppData\Roaming\Secondlife I havnt seen the IM/Profile problem myself but web profiles are pretty futzed right now and have been since this post: http://status.secondlifegrid.net/2013/12/12/post2134/ which is still not resolved.

JoannaVou wrote: I discovered that the blurriness is connected to my pofile photo. I was using the same photo I had in my SL profile as in the picture frame. When I changed my profile photo to another that I don't have framed the blurriness went away from the frame. Well done on finding that. It is indeed a bug and a very strange one. If you use a certain texture for a profile image or picks image or groups image, that texture can act very strangely when its used on inworld prims. Even weirder, if another avatar in range of you has a certain texture as their profile/group/picks image and you apply that texture to a prim inworld, you will see the same bug. This bug only affects V2/V3 based viewers. Here is one example repro that will show the bug easily on any V2/V3 based viewer: For one of your groups, set the group texture to Plywood from the Library. Rez a cube and texture it with the same plywood texture from the library. Change texture repeats on the cube to be 4 horizontal and 4 vertical. Observe the broken texture on the cube. Login a different avatar to observe the cube - they will see the texture broken also as long as your first avatar is still nearby. Change the groups texture to something different, log out both avatars and relog with one avatar and observe the cubes texture now looks correct. The blurry image that you saw inworld when using the same texture as you were using on your own profile is a little tricker to reproduce but it is basically the same bug as the above repro.

The upload crash is a known issue on Mac when coverflow is enabled. Do you still crash if you disable coverflow?

I just did a quick check on the RC sandboxes and main channel sandboxes for return to last position, using the copy/paste object parameter feature and the align tool with Firestorm viewer and everything appears to be working as expected. My only fail was restoring to last position on the BlueSteel sandbox but this was because there is a parcel there at <0,0,0> where I do not have rez rights, so failure was expected.

Pamela, just a thought but do you have the option "Hide selected" enabled? This would make any object disappear while you held it in edit. I dont know where this option is on Singularity but on V3 based viewers it is under Advanced -> Highlighting & visibility -> Hide selected.

Maestro, unfortunately Viewer 3 does not have return to last position or the copy/paste object position or the align feature. Those are TPV features only. I'll test these on Firestorm and JIRA if it appears serverside changes have caused some breakage there. I suspect there isnt a server problem or we would have heard much screaming in Firestorm support by now as those features are widely used.

Do you have the ability to build at <0,0,0> on that region? Return to last position will only work if you have the ability to rez at <0,0,0>. This is a server limitation. Can you reproduce the same problem on another viewer that has the copy/paste object position and the align feature? Can you reproduce it also on another region? That would help to narrow down if this is a region problem or something that changed in the server update or if its a specific issue with Singularity.

Yes please :smileyhappy: If you are using a viewer that does not have your card added to the gpu table, it will not cause a crash, you just will not be able to enable shaders, so something else is wrong here. Your system information will give the viewer you are using, operating system, how your card is detected by the viewer and driver version so yes, please give that. Then we can look if that viewer has your card added to the gpu table for a start. I suspect the login crash is because of the driver version tbh, but lets see

Can you get as far as the login screen? If so, go to the top menu bar, Help -> About Secondlife/viewer name, copy all your system information and paste it into a comment here.

Its a Mac specific bug. See STORM-1976 - When pasting from a web browser or some other applications into the viewer, some garbage characters are appended