🪰 Viewer Bug Reports

See https://jira.firestormviewer.org/browse/FIRE-36985 . Official sl, firestorm and other sl viewers have multiple instances in the dock and at activity monitor. It happen when i startup a viewer and i can quit them but they appear sometimes when i teleport again. It is only with sl viewers for me, not with other apps.

Hello Firestorm Support Team,My viewer is constantly crashing whenever I visit crowded events or parties, but it works perfectly fine when I am alone at my home region.The viewer triggers a buffer overflow protection error with the following message: "LLTemplateMessageReader::getData : Msg ObjectUpdate variable Data is size 16128 but copying into buffer of size 16".It seems like a corrupted or oversized attachment/object from another avatar is triggering this network message error and bringing down the viewer.

Persistent error message for weeks across a dozen accounts. This interferes enormously with work flow for those of us with multiple alt accounts needed to hold together groups or maintain themed sims. Each and every time, each and every account is viewed and attempts are made to pay tier bills, the page is blocked with the "confirm email" demand and then when we attempt to comply the error results (and in fact it is not needed). Every single account has been email verified -- and repeatedly verified in accordance with intrusive LL demands in recent months. But now the system is throwing up errors asking YET AGAIN REPEATEDLY for email verification when it was made multiple times already. Worse, if you click on "Send Confirmation email" -- which you MUST DO because your page will not even open AND you cannot exit to another account! -- then you get the "Email Verification Error" as a result. This is so annoying and so obvious that it's hard to believe Lindens themselves aren't experiencing this with their own accounts and motivated to fix it. There isn't a category for "My Accounts Page" so I am forced to put this under the wrong category. Let me also take this opportunity to note that MFA should NOT be forced on the user population and should only be an option of choice. Most people get it that they need to change their password often, make it strong, and never give it to anyone. Most people are happy to verify email a reasonable number of times a year -- but not upon every log-on! There is no need to join the throng of obsessives demanding 2FA which really turns into MFA nowadays requiring both emails and mobile phone codes. We've been asked to verify email even with old accounts that have unchanged email for decades. We have done so. Obviously there is an error (see below). Fix this please.

Hello ! I noticed the bug on Firestorm Viewer. When I conctacted the Firestorm support, they told me they are able to reproduce the bug on the Official SL viewer so it's a Second Life issue. The bug is easy to reproduce See the two attached file. The first one is a snapshot preview. The second one is what I get when I save the snapshot to a file. The 5:1 ratio is extreme but I also notice difference with standards ratio such as 3:2, 1:1 or 4:3. The differences entre the preview and the file are less visible but they exist.

Second Life keeps crashing on both the regular viewer and Firestorm viewer whenever I am on a busy sim. It will happen even when there's only about 10 other avatars around me/ I tried clearing my cache, lowering graphics, filimg an AMD report and turning off play media and it still is not helping. My laptop is only three years old so that's not the issue either.

Rez any prim/object in-world. Place a script inside the object that calls llDie() after a short timer, Set the object temporary, or simply have another user delete the object when instructed to do so. Add any second inventory item into the object (e.g., a notecard, landmark, or script). Right-click the item in the contents tab and select Rename so the inline text edit field is active with keyboard focus. While the text editor still has focus and there is a pending change to the name, trigger the destruction of the object. Observed Result: The viewer crashes to desktop immediately. Expected Result: The rename operation should abort cleanly without crashing the viewer. Suspected cause: The rename isn't canceled when the object is destroyed: When the containing object dies, LLPanelObjectInventory::clearContents() queues the scroller for deletion (die()) and sets mFolders = NULL. However, it never cancels the active rename or drops keyboard focus from the text field (mRenamer). When LLMortician cleans up the views on the next pass, LLFolderView::~LLFolderView() runs first and sets mViewModel = NULL. As the base destructors finish tearing down the view hierarchy, focus is finally stripped from mRenamer. Because the field is set to commit on focus loss, it tries to finish the rename and calls arrange(). Inside arrange(), it calls getFolderViewModel()->sort(this). Since mViewModel was already cleared in step 2, this immediately blows up with a null-pointer dereference (0xC0000005). Fix: The fix is to cleanly cancel the rename and drop focus before destroying the views, rather than letting focus loss trigger a commit during teardown. Add cancelRenaming() to LLFolderView : Disables commit_on_focus_lost , removes the popup, and cleanly releases focus. Cancel renaming during cleanup: Call cancelRenaming() in ~LLFolderView() , deleteAllChildren() , and LLPanelObjectInventory::clearContents() . Add null checks: Guard against a null mViewModel in commitRename() and finishRenamingItem() so arrange() won't attempt to sort a destroyed view. I've created and tested a working fix here as an example https://github.com/soapyf/slviewer/commit/9e7da4917065b857cca6f1954721dcce8e5b2fd7 And I have also submit it as a PR https://github.com/secondlife/viewer/pull/6321

The new PBR Nacon environment settings that were recently added to the inventory library are set to no transfer, this prevents them from even being moved out of the inventory to edit them I assume this isn't intentional, and if not I think they should be changed to be full perms like all of the other environment settings

Create a simple cube (mesh or prim) and scale it to 0.3, 4.0, 4.0. Create another cube, scale it to 4.0, 4.0, 0.3 and place it on top of the first one. Set the sun azimuth so that it shines onto the wide side of the first cube. Move away from the objects and observe that the shadow changes; there is now a fully lit band of light directly underneath the second object. This seems NOT to be not related to: • Materials/PBR -- adding a PBR material does not change this behavior. • Geometry -- the objects are watertight. • LOD -- a mesh cube with all LODs using the full geometry behaves the same. • Physics Shape Type -- Convex Hull and Prim behave the same. I have found only two factors that affect this: Top object thickness -- the effect kicks in farther away with thicker objects. The Draw Distance -- the effect kicks in farther away with lower distances. Interestingly, moving the top object up so that there is a gap between the two object changes the behavior and reduces the effect; see the attached image. PS: I realize that this may not technically be a "light leak" -- but I couldn't think of a better term. PS 2: I have tried to think of ways of designing around the issue, but I don't think there are any realistic options. Most non-trivial structures will encounter this issue in some form or other.

I opened a bug with support (#2561809) to see if maybe LL had recently changed the clock in one of the regions, and was told to vote for this other issue: https://feedback.secondlife.com/bug-reports/p/fix-eep-mainland-environment-cycle-are-way-too-dark That doesn't look like the same problem to me. The other issue is about overall brightness, but THIS issue is about the SUN ANGLE being different on two border-adjacent parcels for no apparent reason, when the region and parcel settings would seem to suggest that it should be the same. Investigation so far: Albion’s region sun position is out of sync with adjoining Noyo even with the same GMT-8 offset. On my parcels (NE corner of Albion + SE corner of Noyo), both set to Use Region Settings, LSL confirms identical day lengths (14,400 seconds) and offsets (57,600 seconds). For Sky Altitudes, both parcels report using "(region environment)". However, late in the day, the sun is visibly above the horizon in one while visibly below the horizon in the other! The same phenomenon can be seen at other times as well. Near-simultaneous llGetRegionSunDirection() readings put Albion’s sun about 29° above the horizon and Noyo’s about 2° below it. Each parcel’s sun direction matches its own region’s. Reapplying Use Region Settings and relogging do not resolve this. Applying the same explicit day-cycle asset to both parcels makes them agree, but puts both of them out of sync (-8 hours doesn't mean the same sun position on these parcels that it does on neighboring parcels). I think someone at LL may have recently changed the region settings in Albion as it wasn't like this a few days ago. Please investigate Albion’s underlying region environment/day cycle and restore consistency with Noyo. Phenomenon observed in both Second Life Release 26.3.0.31203661088 (64bit) and Firestorm 7.2.4 (80712) Jun 1 2026 12:24:09 (64bit / AVX2).

In profile picks, when creating a new pick or on set location for an existing pick the co-ordinates are now incorrect. Sometimes the X and Y are correct, sometimes they are incorrect. The Z co-ordinate shows as 0. The correct co-ordinates show initially, but when selecting create pick, they change to incorrect ones. The worse example of incorrect co-ordinates can be found at this location https://maps.secondlife.com/secondlife/Fog%20Bank/106/209/3000 create a new pick here, correct co-ordinates shown, then save pick and it has always changed to 128, 128, 0. More information can be found in this SL Forums topic https://community.secondlife.com/forums/topic/534771-the-new-mystery-of-location-height/