Server Bugs

Since around 1.5 weeks (22th/23th July, I would say), I become moved (after logging out on "my" Sim) on the log-in to various SafeHubs. This happens if I log in at the Sim, I was on at logout ... same as if I I try log in "at Home". It happening to me 100% on "Demelo" (RC LeTigre, Mainland, Full Region) ... ... if I log-out/in on "Fishergate" (RC Magnum, Mainland, Full Region) it happens rare, maybe 25% ... ... doing it on "Podyan" ("Second Life Server 2026-07-10.29122504250", Mainland, Homestead) it nearly never happens. "location not available" usual meaning, the Sim is down or overfilled or have other troubles. But the Sim is online and "normal" working ... people (and also my Bot/scripted Agent) are on it. If I try then from the SafeHub a Teleport-Home, it average fails. Doing a TP to one of the Sims around, it mostly gone right ... and I can walk over the Sim-border with no problems. Also doing first a TP to "somewhere" ... and then TPing to Home ... works ("as usual/typical"). The "log in"-problem is happening also to other people ... (where some complaining then also "why them are not allowed ...", as them think, they being banned). Also the Teleports are sometimes need very long time. Some people reporting, them was need multiple times to finally TP successfully ... (and sadly not all have that patience). After the "Rolling Restarts" last week (29th July ?), the Sim seems to was show the "Failed to grant capabilities"-error or so ... ... and someone was request a restart at the support ... and for "1 day" the log-in fail was gone (then it came back). As a little side-note: The mobile Viewer becomes redirected to the "Campwich Forest"-Sim ... this seems to be a "mobile Hotspot" and not a SafeHub ... and it is "Moderate"-rated only, not "adult".-rated, as "Demelo", which can cause problems about the appearance on an other rating.

URGENT SECURITY VULNERABILITY – UNAUTHORIZED EJECTS AND FALSE OBJECT ATTRIBUTION I am reporting what appears to be a serious security vulnerability in Second Life involving unauthorized parcel ejects. Residents are being forcibly ejected from parcels by users who do not appear to have the required land ownership, estate, or administrative permissions. This is not limited to a single incident or a single parcel. Multiple residents and lands appear to be affected. A particularly concerning aspect is that the system appears to attribute the action to an innocent object. When an eject occurs, the victim or nearby residents may see a local chat message such as: “The object 'Void - Demure Lashes (Avalon)' at Dearheart (196,46,2338) cannot teleport the parcel owner home.” The referenced object is a cosmetic attachment with no eject or teleport function. There is nothing in the object intended to eject, teleport, or remove users from the parcel. Nevertheless, the system displays the object as if it were involved in the action. This creates the appearance that a legitimate object caused the eject, while the actual source of the action appears to be something else. In one ongoing case, a resident has reportedly been ejected repeatedly, potentially dozens of times per day, across different locations. Entire groups of visitors on a parcel have also been forcibly ejected without authorization. We have already submitted multiple Abuse Reports and contacted Live Support, but the underlying issue remains unresolved. We urgently request that Linden Lab investigate this as a potential Second Life security vulnerability or exploit, rather than treating each incident as an individual land-management issue. Please review the server-side logs associated with the affected parcels and accounts, including: • The exact timestamps of the eject events • The account or system component actually triggering the eject • The permissions involved • The source of the eject request • Why an unrelated object is being displayed as responsible • Whether the same mechanism is being used across multiple regions and parcels If possible, please reproduce the behavior in a controlled environment and investigate how a resident without the appropriate permissions can cause another resident to be removed from a parcel. This issue is creating serious harassment and security concerns for residents and landowners. We need the technical/security team to identify the underlying cause, fix the vulnerability, and prevent unauthorized users from abusing this functionality. This report concerns a suspected platform-level security vulnerability, not a normal parcel eject performed by an authorized land manager.

I first became aware of this when I noticed my aircraft weren't going into "taxi" mode on landing. It was hard to chase down the origin of this behavior, but I eventually discovered that a script containing collision_start()/land_collision_start() event handlers was being TURNED OFF on region crossing... but only on rare occasions. I might cross 20 borders without this happening, or even 50 or more. It seems like it's more likely to happen in certain areas, such as the stretch of sims starting just south of Santa Catalina and continuing east across the Blake Sea to that giant four-sim airport in the Norwegian area. I suppose if they're homestead sims, that could explain why that particular area seems more susceptible to it. That has been by far the most reliable place for reproducing this bug. I grepped all of the scripts in the whole object for llSetScriptState() calls. There are none. (No reason there would be in the first place.) I found that removing an llSleep() call just after a collision_start() event caused the rate of the script halting to be greatly reduced. I theorize that the chain of events is something like this: Vehicle crosses sim border. Occasionally, this causes a spurious collision_start() or land_collision_start() event. (This happens well up in the air, obviously, so it isn't a "real" collision. Probably a race condition between the vehicle and avatar entering the sim in some stochastic order.) Something about the invocation of llSleep() when the vehicle is still actively being handed off fritzes something in the simulator; and it responds by halting the script, OR by failing to return control after llSleep()'s time has elapsed. Whatever the cause, the script's "Running" checkbox is disabled, and it is quite inert.

After teleporting between two RC BlueSteel regions, I noticed that my viewer was still connected to both regions even after an hour later. Using Firestorm's nearby people list, I can still see specific people moving around as if they were in a region adjacent to the one I was in, well past the 60 second mark when my viewer normally disconnects from a region I left. Steps to reproduce (Firestorm viewer) Teleport to BlueSteel Sandbox 1 . Teleport a friend to you and have them remain there in BlueSteel Sandbox 1. Teleport to Sandbox Cordova . Wait at least 60 seconds. Open the Nearby People list (Ctrl + Shift + A) and look for your friend's name. If your friend is still in the Nearby People list, then you are still connected to BlueSteel Sandbox 1. You can even double-click their name to put your camera on them and see them move around. Teleport your friend to you and have them remain there in Sandbox Cordova. Teleport back to BlueSteel Sandbox 1 . Wait at least 60 seconds. Open the Nearby People list (Ctrl + Shift + A) again and look for your friend's name. Your friend's name should no longer be listed, indicating that you have disconnected from Sandbox Cordova.

I am in a private call. I teleport away from the region where I am speaking to a friend. I have voice for maybe 10-30 seconds in the new region, then it fails. In the chat box it says "[5:44 AM] Second Life: Lycan Drascol started a voice call [5:44 AM] Second Life: Lycan Drascol started a voice call" over and over until you hit the call button to stop it. Then you cannot reconnect to voice. I teleport back to the region I started at but I still cannot connect to voice either in local or private unless 1 or both of us relog. It does not appear to matter where I teleport to, the outcome is the same. Unless my friend comes with me, then we can stay connected.

Individuals using a program called <something>, they enter the region, grab the IP address and port number for the hosting server, and they proceed to launch and attack using the program on their desktops. This causes the region to go offline, and you are only able to bring it back online using the secondlife.com portal. After a year of experiencing these crashes on a daily basis in my region, I was finally able to find out what was going on. (I've never used this JIRA before, so I am not sure if this is the right place to report this) Please someone come up with a solution to this. It's been a long 12 months experiencing daily crashes in my region. I've spoken to various representatives via an open ticket that I have and no one has been able to help me.

I am a Premium member, but I got a message when I logged in yesterday that I had too many IMs and they were capped, even though I had only 29 Notices and 2 IMs waiting for me when I logged in. I would have been at my skybox in Morning Shire, where I usually log in. I didn't think to take a screenshot at the time; if it happens again, I will add that to this report.

Attempts to upload textures produce the following errors: "unable to upload due to the following reason: service unreachable." "unable to upload due to the following reason: internal error from verifier." Steps to reproduce: Visit Cloud Sim 1 or 2 on Aditi Grid Riders Test Channel 2024-07-15.9943229367. Here are two convenient locations to try: secondlife://Aditi/secondlife/Cloud%20Sandbox%201/247/12/27 or secondlife://Aditi/secondlife/Cloud%20Sandbox%202/245/245/27 Attempt to upload a texture Texture upload fails. Adjacent sims running on Second Life Server 2024-06-11.9458617693 are able to upload textures ok.

on the 5th I started seeing failures with external HTTP in requests to inworld objects... Failing with a 502 Proxy error. After some experimenting, it only happens on RC BlueSteel, RC LeTigre, and RC Magnum servers that I've tested on, AND the POST body must be non-empty. If I do a post with no body (from external, i.e. my web server) with an empty body, it works everywhere. With ANYTHING in the body, it fails on RC servers. non-RC release regions do not fail! Everything works fine. GET requests all work fine everywhere, too. It's only POST, with body, to objects in RC regions from outside SL. I've been making many HTTP-in POST requests from my web server daily to objects all over the grid for a very long time now. I haven't changed a thing and this new behavior just started showing up a few days ago out of the blue. It's causing some of my scripted products to completely fail to function, it's a really big problem for customers. This affects RFL inworld fundraiser kiosk servers so this could cause a big disruption to their fundraiser. However they may be able to temporarily mitigate by moving all their inworld servers to a non-RC region. This is a really big problem for me since I have no access to a non-RC region. All my land is apparently RC.

Go to Premium Voice Morphing services. Touch the kiosk you wish to use, You will get this response.........Your request is being processed... [15:46] MegaMorphs: Thank you for subscribing to Second Life Voice Morphing! Click secondlife:///app/voice/effects/refresh to activate the new voice morphs in your viewer. When you touch the secondlife:///app/voice/effects/refresh nothing will happen. I also tested this on the Firestorm Viewer with the same results.