these memory leakes are resualting in packet loss, Lag,
Second Life 1.18.4 (3) Nov 7 2007 11:19:15 (Second Life Release)

You are at 282700.6, 279081.9, 25.3 in Ghloogums located at sim2880.agni.lindenlab.com (64.129.43.122:13006)
Second Life Server 1.18.3.72843

CPU: PowerPC 7450 (1249 MHz)
Memory: 768 MB
OS Version: Darwin 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA NV34MAP OpenGL Engine
OpenGL Version: 1.5 NVIDIA-1.4.18
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Packets Lost: 203/41814 (0.5%)

2007-11-08 15:04:22.273 Second Life[1994] *** _NSAutoreleaseNoPool(): Object 0x81ae920 of class NSMutableParagraphStyle autoreleased with no pool in place - just leaking
2007-11-08 15:04:22.273 Second Life[1994] *** _NSAutoreleaseNoPool(): Object 0x838eaa0 of class NSCFDictionary autoreleased with no pool in place - just leaking
2007-11-08 15:04:22.279 Second Life[1994] *** _NSAutoreleaseNoPool(): Object 0x8390160 of class NSView autoreleased with no pool in place - just leaking
2007-11-08 15:04:22.281 Second Life[1994] *** _NSAutoreleaseNoPool(): Object 0x8390160 of class NSView autoreleased with no pool in place - just leaking
2007-11-08 15:04:22.281 Second Life[1994] *** _NSAutoreleaseNoPool(): Object 0x8390160 of class NSView autoreleased with no pool in place - just leaking
Nov 8 15:51:28 rascal crashdump[2037]: Second Life crashed
Nov 8 15:51:32 rascal crashdump[2037]: crash report written to: /Users/adammblades/Library/Logs/CrashReporter/Second Life.crash.log
2007-11-08 15:53:19.641 Second Life[2041] *** _NSAutoreleaseNoPool(): Object 0x79766d0 of class NSMutableParagraphStyle autoreleased with no pool in place - just leaking
2007-11-08 15:53:19.642 Second Life[2041] *** _NSAutoreleaseNoPool(): Object 0x7b7f940 of class NSCFDictionary autoreleased with no pool in place - just leaking
2007-11-08 15:53:19.661 Second Life[2041] *** _NSAutoreleaseNoPool(): Object 0x7b812a0 of class NSView autoreleased with no pool in place - just leaking
2007-11-08 15:53:19.663 Second Life[2041] *** _NSAutoreleaseNoPool(): Object 0x7b812a0 of class NSView autoreleased with no pool in place - just leaking
2007-11-08 15:53:19.663 Second Life[2041] *** _NSAutoreleaseNoPool(): Object 0x7b812a0 of class NSView autoreleased with no pool in place - just leaking

This is taken from my Console. log

thanks and best wishes
Keris

and im having these issues with following comp specs.

MSI K9AGM2
AMD Athlon 2400+ X2 x64
2048MB DDR2 667 memory
NVIDIA GeForce 8800 GTS 320MB

been tryin several settings and options, clearing cache etc.
but all doesnt make any difference.

only in more empty sims i seem to get the worse lock ups which are forcing me to relog.
so i think it has some serious memory leaks, or file/memory accessing issues.

The easiest fix on my computer is to turn off Object-Object-Occlusion (Client->Rendering->Object-Object Occlusion or just Cntl-Shift-O). That pretty much stops the leaking on my system and enables day long SL sessions.

Intel based Macs use the same Key commands as Windows.

It would be really nice if LL stopped adding new features to the client until the current bugs are resolved. But then, it's so much more fun to add new features than clean up the mess made by previous additions.... sigh.

I upgraded to 3Gb. And it's stopped.

I hope this never happens,but unfortunately it looks like it could be inevatable if this issue is unresolved

CPU: Intel Pentium 4 (Unknown model) (3192 MHz)
Memory: 3071 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 6800/PCI/SSE2
OpenGL Version: 2.1.1
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)

If SL is becoming such that the only way to properly play it, is to have a high performance computer with 1 plus gigs of ram, and two plus GHz of speed then I lot of people will have to stop playing,

Also, nicholaz's client has a lot of memory leaks patched.

I wonder, are those memory leaks gone due to rewritten modules or are there also some fixes that could be merged to the mainstream. Anyway, as I often say lately, hoping for better times. But I suppose even if you get rid of all of the leaks, there is also the heap fragmentation, which is harder to address...

SL (windlight) is unsurprisingly the top memory user. At 1.08 GB currently. That's rather a lot. I've been logged in for several hours, and am in a moderately busy area with 160 draw distance. 2 avatars in sim, including me.

Firefox is at 306Mb, which is also pretty large. I wonder how the new firefox beta compares.

Honestly, I think the minimum requirements for SL should say 2GB of RAM. 512 is really unrealistic, and 1GB barely copes.

core2 quad Q6600 at 2.4GHz
2 gig of ram
dual nvidia 8600 GT in SLI mode
Vista home premium

My benchmark attribute is Page File Usage because it is so easy to view on XP in Task Manager. I have a new machine as well (3.0G dual cpu, 2G matching ram, 8800GTS w 640Meg) and before I turned Object-Object Occlusion off I could watch PF Usage clime steadily until it reach over 2G, and then I would crash. The client would simply vanish without a trace in 20-30 minutes tops. I suspect that having higher-end components exacerbates the problem somehow.

After turning off Object-Object Occlusion I could run for many hours wihtout a crash and my PF Usage behavior and failure mode changed in three ways. First, the increase PF usage was slower. Second, at times I recovered PF memory - SL actually gave it back (sometimes when TPing, for example). IOW, PF consumption was no longer monotnically increasing. Third, I could attain levels of 2.5G PF usage before crashing.

The instability still sucks, but this little tweak is a good one.

This is just sad as I cannot do a simple transaction without having to STOP and wait to start up second life again from these spontanious crashes.
I just wish Linden Labs would just fix these problems without having to add so many things in the process.

They are thinking about

QUALITY
over
EFFICIENCY

Which in my opinion is very bad. I hope Linden Labs notices that before they get too overwhelmed with it and it becomes a major issue as it already is becoming now.
Personally, and I don't mean any offense to Lindens or the Creators.

But I don't think the Lindens are hearing the cries of the Residents, just a soft whisper in the darkness until a mass majority as we see now of 88 Votes and all these comments arises.

I CANNOT LOG INTO SECOND LIFE AS OF NOW.
Permanently.
It is over, I cannot log in, I cannot do anything, The moment I connect to the world, POOF.

I have updated my video card drivers and the latest SL clients ... no luck.

I've got a new video card on the way in hopes that will maybe fix it .. but I don't know now, after seeing this bug.

Any tips or help would be much appreciated!

BTW, I've confirmed the others were incidentally running the same processor P4HT and an ATI Radeon card.

Also, I have seen the memory leak error warning popup on my laptop now. This laptop also runs ATI graphics.

Specs:
Intel E6850 Core2 Duo 3.0GHz
2GB DDR2 RAM
Nvidia GeForce 8800 GTS with 512MB RAM
Windows XP SP2

It does seem that SL really isn't happy with many PC clone computers that have memory lower than 2-3 GB, and video cards lower than GeForce series 7xxx or equivilent (that are AGP instead of PCIe x16). I reccomend people upgrade to motherboards with 2, 3 or 4 PCIe x16 slots and 800 MHz DDR2 RAM memory slots, but for those who cannot do such an upgrade, this bug or series of bugs needs fixing.

Hardware Overview:

Machine Name: iMac
Machine Model: PowerMac6,1
CPU Type: PowerPC G4 (3.3)
Number Of CPUs: 1
CPU Speed: 1.25 GHz
L2 Cache (per CPU): 256 KB
Memory: 768 MB
Bus Speed: 167 MHz
Boot ROM Version: 4.6.8f4

GeForce FX 5200:

Chipset Model: GeForce FX 5200
Type: Display
Bus: AGP
VRAM (Total): 64 MB
Vendor: nVIDIA (0x10de)
Device ID: 0x0329
Revision ID: 0x00a2
ROM Revision: 2068

DIMM0/J22:

Size: 512 MB
Type: DDR SDRAM
Speed: PC2700U-25330

DIMM1/J20:

Size: 256 MB
Type: DDR SDRAM
Speed: PC2700U-25330

Total memory 768 MB DDR SDRAM
1.25 GHz PowerPC
Tiger 10.4.11

OS Name Microsoft® Windows Vista™ Ultimate
Version 6.0.6000 Build 6000
OS Manufacturer Microsoft Corporation
System Manufacturer NVIDIA
System Model EVGA 132-CK-NF78, 780i chipset
System Type x64-based PC
Processor Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400 Mhz, 4 Core(s), 4 Logical Processor(s)
BIOS Version/Date Phoenix Technologies, LTD 6.00 PG, 1/16/2008
SMBIOS Version 2.4
Windows Directory C:\Windows
System Directory C:\Windows\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "6.0.6000.16407"
Total Physical Memory 8 GB at 800 Mhz
Available Physical Memory 6.75 GB
Total Virtual Memory 20.42 GB
Available Virtual Memory 19.01 GB
Page File Space 12.70 GB
Page File E:\pagefile.sys
Graphics Adapter Description NVIDIA GeForce 8800 GTS 512
NVIDIA GeForce 8800 GTS 512
Running in Sli

On my Tiger with 2Gb Ram and 2.2MHz Processor, I use p about 2.5 Gb of Ram/Virtual Memory within about 30 minutes. At that point everything freezes and the paging completely hoses my system.

I'd be happy to add more details. So far this is my first post to the site. I'm hopeful that the Linden devs can use the info here. I'll have to quite SL soon if I can't play on it.

If details would be helpful, just ask. I kindof suspect that enough details have already been given, but I could be wrong.

Drew

I'd like to know what my 10 dollars per month is going to, playing the game, or paying to fix it?

Better yet the people who have to pay for land tiers, I feel sorry for them

I was playing for a month before this started...

wake up lindens!!!! i want to get back into my game. im a premium member and i think right now im being overcharged for a service i cant use.. is no one testing these cards. they are more than compatable with secondlife.

Thread 0 Crashed:
0 com.secondlife.indra.viewer 0x0083142c LLError::crashAndLoop(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 4
1 com.secondlife.indra.viewer 0x008332fc LLError::Log::flush(std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >*, LLError::CallSite const&) + 1864
2 com.secondlife.indra.viewer 0x00819df8 LLGLImmediate::flush() + 224
3 com.secondlife.indra.viewer 0x007706c0 LLImageGL::unbindTexture(int, unsigned) + 48
4 com.secondlife.indra.viewer 0x0049b10c render_disconnected_background() + 3580
5 com.secondlife.indra.viewer 0x0049c308 display(int, float, int, int) + 4392
6 com.secondlife.indra.viewer 0x007dd7dc LLAppViewer::mainLoop() + 1468
7 com.secondlife.indra.viewer 0x007e3ae0 main + 580
8 com.secondlife.indra.viewer 0x0000266c _start + 760
9 com.secondlife.indra.viewer 0x00002370 start + 48

LLGLImmediate::flush() is checking
if (mCount > 0)
{
if (!sStarted)

glDrawArrays(mMode, 0, mCount);
mBuffer[0] = mBuffer[mCount];
mCount = 0;
}

and hits the error condition which means LLGLImmediate::stop() had been called to set sStarted to false.

render_disconnected_background() only gets called

if (gDisconnected)

which means LLAppViewer::disconnectViewer() had been called

so it looks like it crashed while shutting down. I don't know what this means, but hope it may help someone.

so they appear to be unrelated.

But in 1.19.0.5 it is killing my SL sessions. The memory used grows and grows and SL slows to a crawl. Is anyone at LL working on this? This is a severe bug in my opinion....

I have been working on troubleshooting SL on my Vista installation for six weeks by now.

I am using a X38 chipset and E6600 CPU, 4 GB RAM, 8800GTS-320 card, and a parallel installation of Windows Server 2003 and Vista X64 and x86.

ANY kind of SL client that I have tried (1.18.5.3, any flavor of 1.19, Windlight or not regardless) would increase it's footprint until it starts popping up out of heap memory errors around 1.3 - 1.5 GB of memory usage in Vista after 2-4 hours of running.

This is VISTA SPECIFIC, I want to stress that. In older Windowses the client would flush old data once you minimize the SL window and barely leave a footprint of 54 MB. And applying a compatibility mode doesn't solve it either.

This definetly HAS TO BE FIXED, people. It doesn't only lead to client crahses but also to total OS crashes.

These people are SUFFERING,
LL is not dedicating their time to it, if half of the people that had the problem were to start working on how to fix it, we'd probably fix it before the lindens did.

I have put in Jira tickets (last one VWR-5521) that haven't been resolved for me since I first reported issues with 1.18.4 and I"ve only just found out that it may be memory leak related - though it's hard to tell.

It´s more important to make a new viewer without to handle old problems?

Severe memory leak reaches as high as 2 gigs and crashes system. This is an all-time high. In the past I have seen it up to 650 megs, even as high as 900+ megs, but never past a gig and never almost to 2 gigs. This isn't improving... it's getting worse.

I am truthfully amazed that after at LEAST a year of this problem existing and documented, a task force hasn't tackled and corrected the problem. I don't want to insult Linden Lab, but that's just poor system management. No self-respecting computer company should tolerate a known memory leak that crashes customer systems. In most professional companies, a task force would be assigned to the issue and have the problem found and fixed with all due haste... or else.

And to be direct, if I was on the LL board of directors and knew about this problem, I'd call in the CEO and CTO and tell them to get it fixed... or else. Truthfully, I've never seen a computer company have problems like this continue for so long and still be in business. One has to wonder how long such problems can continue with out dire consequences. Curiouser and curiouser.

SL didnt crash but an annoying message did come up every 3 seconds so i had to shutdown the client

"SmartHeap Library"
"Out of memory. Please free some memory, then choose retry."
"Abort / Retry / Ignore"

-----------------------------------------------------------------------------------------------------------------

Second Life 1.20.10 (89467) Jun 10 2008 18:17:42 (Second Life Release Candidate)

You are at 255631.8, 244431.7, 23.7 in Wezen located at sim2760.agni.lindenlab.com (216.82.19.3:13001)
Second Life Server 1.22.3.89352

CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3000 MHz)
Memory: 3327 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9800 GTX/PCI/SSE2
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.15886 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 4/23555 (0.0%)

-----------------------------------------------------------------------------------------------------------------

Nvidia Driver Version: 175.16
CPU is a Core 2 Duo E8200 @ 3 Ghz
4 Gigs of Ram

MacPro early 08, Dual Quad core Intel 2.8, 6 G ram, Ati Radion HD 2600 w 256 M Vram, OSX 1.5.3 9D34.

What the hell did they change between 4 am and now?

I'm using a a MacBook Pro running Mac OS X 0.5.3. 2.4 GHz Intel Core 2 Duo processor, 2 GB 667 MHz DDR2 SDRAM, 4MB L2 cache, bus speed 800 MHz, 256 MB VRAM. ADSL modem 24 Mbit/sec ; computer-modem connection via ethernet. Nothing exceptional about connection speed (usually pretty good and stable at 12-13 Mbit/sec) or packet loss.

I've tried both the RC and the regular client and none of them work so at the moment I have no possibility of doing anything meaningful in SL.

All the symptoms are the same as in previous reports the about severe lag using the MacBook Pro. Hence it would appear that perhaps a solution similar to that applied to earlier server versions might at least partially remedy this problem also this time. Is anyone checking up on this?

Hello Linden Lab are you there?

Huston, we have a problem.

We see above that Mac users with ATI cards are having the same problem.

Point made Alexa? Memory leak, not graphics card problems. Again, time for Linden Lab to take responsibility for its problems instead of trying to foist the blame on customers, their computers, or other companies.

When we have Macs running ATI graphics cards and PCs running Nvidia graphics cards and they're all having the same problems, and all are high-level systems, that rules out Windows, Mac OS, Nvidia or ATI as the culprits. It means the cause of the memory leak is Second Life Client Software (or one of the platforms upon which that software is based. Either way, it's Linden Lab's responsibility).

Since this report was initially filed in NOVEMBER 2007, and repeatedly filed in other JIRA's since then, and with a realatively whalloping total of 157 votes... I would recommend at this point your company calls in a third-party expert to fix a problem Linden Lab appears unable to fix. Scuse me for being blunt, but allowing a severe memory leak to continue for that period of time is unprofessional and irresponsible to your customers. Plainly stated: at $295 and $350 a month for sims... we deserve better.

SL was my every-evening-joy. But I am fed up. I crash after 2 minutes in average SINCE MONTHS. So often I crash even before opening the first screen: This means, that my IMs are lost, group invitations are gone. One group invitations was sent to me for 5 times. Not one single time SL was long enough online to say "yes" to it.

On crashing every some minutes I loose the money I put into gaming machines, because the game times out. I loose my work on building, because every edit-window and open textures are lost.

You will not enjoy anything, if you wiil be interrupted after very few minutes! And then, "the system is currently logging your out - wait another minute." grrrr
I reduced the play SL time drastically over the past weeks. The frustration became too high.

LINDENS:
Why don't you stop this "making new things" for a while and trying do work with higher quality? You cannot do it within "one campainge month". To get rid of all this bugs takes its time. Give yourself this time. And if you think, the time is enough - double it up to be realistic.

Keep in mind, that you failed for 6 years to create a robust software. What are e.g. 6 months for improving this chaos against that?

First, a Kudo for the well-worded manner in which you stated the solution for SL woes in your section headed "LINDENS". A professional consultant couldn't have put it better. You are 100% right... taking 6 months to heavy-focus on bugs would be a wise investment on LL's part. Because if they don't, within the next 2 years another company is going to come along and steal the majority of LL's market. There are already about 2 dozen companies poised to do so, not the least of which is the Open Sim project. Linden Lab needs to clean their house, or risk losing it.. Not trying to be crass, just stating a fact: there are currently so many SL customers that are upset with instability and performance issues, coupled with poor LL customer interaction, that they're willing to jump ship at the first viable option (so LL's house-cleaning includes stepping up concern for customer needs above the profit line... and stoping arbitrary decisions that just about anyone could tell them is against the best interests of their customers). Another thing they are going to have to realize is that charging high prices for stacked servers is not being fair to their clients. If they were charging $75 to $95 for a full sim... they might be able to stack servers. Someone paying $295 a month deserves a dedicated box at full speed, without resource competition from 3 other sims. These are other issues, but they all tie in with the points you made: LL needs to start focusing on a proper platform and lay off the candy for a while.

Second, a possible solution to your crashing problems. It sounds typical of issues that have plagued people ever since LL hit us with the Windlight / Havok 4 double-whammy in the same week. As much as we all looked forward to Havok 4, it seems to have caused more problems than it solved... and Windlight, as gorgeous as it is, simply overwhelms the majority of the home computers out there. I know when they brought it out, their user base dropped significantly. Bad decision on their part... again.

The likely solution for you is simple, but not obvious. LL has made (IMO a serious error) in setting the SL default to "too-dang-heavy" for the standard system. So...

First, totally uninstall and reinstall Second Life. That will start you out on the new platform. Use the standard version, not the RC (which is riddled with major bugs and problems at this point).

Then, on the SPLASH SCREEN, the once-very-obvious PREFERENCES button has been moved to a drop-down menu choice at the top of the screen. Go into PREFERENCES / GRAPHICS, click the CUSTOM button, and turn off the SHADING section. Also lower all other graphics options to about half their current settings. Save it all and enter Second Life.

Chances are, you'll be able to run the system for more than a few minutes without crashing. Hope this helps.

To recreate quickly:
1. Set draw distance to maximum.
2. Encounter a lot of avatars.
3. Move from one end of sim to other and back again. (Re-encountering the same avatars after moving out of draw range seems to cache the same textures over again without freeing the previous instances.)

To mitigate the problem:
1. Keep draw distance set low.
2. Go to low traffic sims.
3. Close app and restart when memory consumption reaches approximately half of virtual memory on system.

Note that all the mitigation steps basically boil down to "don't encounter other users" which is a pretty silly thing to advise users of a virtual world to do. I consistently exhaust my 2GB RAM system in 15-20 minutes in sims with only 5 other avatars around, requiring a relog to return system to usability.

On another note, I am floored by the fact that this bug has been unresolved for 8 months with no indication that anyone has even attempted to look at the problem. I have a hard time believing there are more important issues to fix than a gargantuan memory leak that limits useful interactivity time to under 30 minutes. Also, it makes no sense to "assign" a bug to WorkingOnIt Linden, which is clearly just a placeholder account and not an actual developer. (Actually, I suppose it could be an real live human being, but this poor sap has over 200 viewer bugs alone assigned to him, so it's really academic whether he exists since it defeats the purpose of prioritizing bugs if they all go to one guy's inbox. By comparison, the actual living developer Andrew Linden has only 34 open bugs.)

There is more than enough data attached to this one issue report alone to recreate, analyze and fix the problem, which doesn't even touch on the numerous other jira issues that are clearly different facets of the same issue. I can only surmise by the lack of action that the development team has either been directed to focus on new work rather than fixing bugs or that the person doing the bug fixing prioritization is the single most inept software project manager in the history of computing. I'm not sure which option I'd find more comforting.

Like you, I have been absolutely amazed at Linden Lab's apparent lack of ability to prioritize computer issues using the concepts established by computer organizations over decades of experience, namely.... usability, stability, communications. They have an incredibly severe memory leak that as you accurately state, has gone uncorrected for months (actually over a year now from what I understand), their platform is so unstable that users crash on a 30% basis, and they can't even deliver a simple notecard to a list of group members (not to mention simple chat between two people transferring out of order). Yet a few months back when I told them that any other computer company would have had a memory leak fixed in a week, tops, a Linden snidely commented on my ability to analyze their systems operation. LOL. What an attitude. (I responded that Linden Lab employees are not the only computer professionals existant).

If I had one bit of advice for Linden Lab it would be this: get your hands out of the candy jar and start focusing on foundation. This kind of nonsense has gone on for far too long... and the long-foretold competition is not only coming, it's already here. Truth: if it weren't for my obligations and dedication to my group and friends, I'd already be focusing on other systems. That's not a good thing, LL. When someone as enthusiastic about VR as I am gets tired of the runaround, SL is in trouble. It's profitable without a doubt; the question falls in two areas: how satisfied are their customers... and how long will it continue to be profitable in the rise of the upcoming VR wave? Do they even care or are they making the typical corporate blunder I see so often these days of trying to grab as much money as possible as quickly as possible and hang the future? I dunno.

I think you said it well Heronimus: "I can only surmise by the lack of action that the development team has either been directed to focus on new work rather than fixing bugs or that the person doing the bug fixing prioritization is the single most inept software project manager in the history of computing. I'm not sure which option I'd find more comforting." I've worked all my life as a professional consultant/systems engineer and corporate watchdog. I could not possibly have said it better. I'm not dissing Linden Lab. I'm shaming the general attitude and lack of simple professionalism... as well as an apparent general lack of respect for their customers. This problem should have been attacked and fixed when it first reared its head. A severe memory leak is not a minor matter; it's the stuff of which system suicide is made.

Considering it's gone on so long, this leaves us with two possibilities: either they don't WANT to fix it, or they CAN'T fix it. As you said, I don't know which is worse. (The only comforting concept here is that both issues CAN be fixed if someone just puts his shoulder to it; fix the attitude or fix the skillset, or both).

Cade... woohoo! I am sure going to try that. While it's a minor pain of a backdoor way to fix LL's problem for them... at least it's a method. Thanks for sharing that!

I have a friend on SL who has, for almost a week now, been experiencing frequent crashes every day ( especially at peak times ) on any sort of turning or movement. Sound familiar? Yup...its the same old issue...complete with errors that seem like memory leaks. In that same time period...I have myself ( and I have rarely had SL issues ) experienced multiple instances of SL freezing up....with graphic driver display errors. Often at specific locations. Even though nothing in my PC setup has changed. And from another SL friend, the exact same issue. Something is patently wrong.

In the case of the first mentioned friend above ( actually my SL partner ) this has made SL virtually unusable ! Nobody wants to have to log in again and again and again every 5 minutes ! In fact if anyone in the LL team want to see the issue occuring.....they are welcome to come to our sim at peak hours and I can guarantee that it can be replicated within minutes.

These sort of issues are turning what should be an enjoyable, pleasant environment into a nightmare where banging one's head against the wall seems to be the only fix on offer.

I would suspect that if any of the Linden team found themselves crashing every 5 minutes....the issue would be fixed in 5 minutes too.

Balpien Hammerer - 23/Jul/08 11:54 AM
Adding additional environment observation: This problem is not related to theopenspace SIM performance cycling problem. I experience the periodic slowdowns on full SIMs too.
[ Show » ] Balpien Hammerer - 23/Jul/08 11:54 AM Adding additional environment observation: This problem is not related to theopenspace SIM performance cycling problem. I experience the periodic slowdowns on full SIMs too.

Balpien Hammerer - 27/Jul/08 03:16 PM
The problem is worse in the latest standard viewer:
Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)

Before, the viewer would slow to a crawl, now it eventually dies with a massive memory leak (crash dumps sent).

Balpien Hammerer - 27/Jul/08 03:16 PM The problem is worse in the latest standard viewer:
Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release) Before, the viewer would slow to a crawl, now it eventually dies with a massive memory leak (crash dumps sent).

Apparently the majority of crashes, a lot of the lag, a lot of problem issues have been caused by this memory leak, and at first glance (without more evidence) this leak seems to be graphics-related. Minimizing the SL Window every 15 - 30 minutes is a cumbersome but effective way to stop this problem on a temporary basis (at least until LL gets it fixed in another year or two. LOL).

Thanks for the clue-in Cade. I sent it to my entire group and you would not believe the number of thanks received for such a helpful tip. You've done a lot of people a real favor by letting us in on this one.

Cade's tip: regularly minimize Windows to reverse the memory leak. You can maximize it right back up again; the minimizing seems to quickly solve the problem, at least for a half hour or so until it builds up again.

It means, the crashes are due to poor memory management of the program SL.
The software asks for memory, memory, memory and does not free it properliy and in time.

I can say what I do: I reduced my play time drastically. I do not enjoy it any more.
My enthusiasm for SL is gone, since my online sessions are split to 2-5 minutes before the next crash.

Yes, I send crash reports every time they work. The have douzends of reports sent from the same crash-situation in the meanwhile.
But nothing happens. I crash again at just the same place some weeks later.

I do not report to Jira any more.
It does not change anything.

Some days ago there was SL in TV: "The hype is over".
This means: Many people feel like me.

Lindens: What may the deep frustration of so many players mean to your jobs?

Hmm....its a bit hard to minimize every 15 minutes when you are crashing every 5 minutes.

We had a "Dragon Fight" event today. During the fight, Dragons would shoot fire that would last 7 seconds. The fire hadn't even rezzed by the time the effect was over! All we could see was gray squares. That is just pitiful.

Considering the small size of a texture file and the incredibly minute amount of time it would take to send such a file across the net and rez it on the screen, textures taking anything more than 1 second to load is a pretty poor sample of programming ability. I would strongly encourage Linden Lab to completely rethink their entire texture loading process. As of now-- it is unworkable and detrimental to everything from basic user experience to shopping.

However, I can give an example:

Imagine in real life, visiting a grocery store... and everything on the shelves is gray. If you focus on any individual item... it takes 30 seconds.. a minute... two minutes to become visible. How long would your grocery shopping take? Well THAT'S how long it takes to shop on Second Life.

In real life... drive down a highway. Now imagine that all automobiles are just gray 2 dimensional boxes. Imagine that all the surrounding country is solid gray. Imagine that such things didn't take detail until quite some time after you passed them. Just how safe would your driving be? How much would you enjoy sightseeing on your vacation? That is what it's like trying to drive a car down a road in Second Life.

Linden Lab, if you want Second Life to be a viable community experience, you CANNOT have textures rezzing so slowly it impacts viability of the system. We can't stress strongly enough how negatively slow texture rezzing impacts the Second Life experience.

PS. btw, same with sounds. Do you realize how goofy SL seems when a sound becomes audible 30 seconds after the gesture has finished... and multi-part music plays all choppy and glitched? Looks amateurish, you know? Does not reflect well on the system or the professionalism of Linden Lab. Not meaning to insult... just telling it like it is.

Also, looking back at my blog comments, I asked our LIndens why they hadn't done a diff to see what broke between RC12 and RC13. It definitely got much worse in RC13. Actually, just having a response as to the progress if this problem would be helpful. Given the official 1.20 is totally fubar, I am no longer running with it. 29 crash dumps seems plenty good for debug analysis. It wojn;t fix my toitally tanked boat business but at least I can enjoy some inworld sailing again, broken SIM crossings notwithstanding.

This bug reads "fix pending". I'll be happy to test an internal fix.

Alas, Wayfinder, slow texture rezzing has plagued us since 1.18.x releases (actually it was the viewers but a massive meltdown in the asset servers that has yet to be fixed.).

I wonder if textures are a cause....or merely a symptom. My own system logs indicate that the latest version of SL seems to be totally intolerant of ANY packet loss..which can lead to a situation where SL simply 'stops responding'. The accompanying graphic driver display errors, and memory errors, quite likely occur after Windows has already lost sight of SL.

Also...I think it highly unlikely that memory leaks are, in themselves, the cause of frequently crashing after just a minute or two. That's not to say that there isn't a memory leak issue.......but that it seems to me that what we have here is not one issue but several related issues.

I am a coder myself.....and often in trying to fix issues, the primary frustration in endeavouring to fix is that of exactly replicating the issue. That's not to say that one just adopts a 'Looks OK to me' attitude, but that with complex code one really has to see for oneself just exactly when and where and how any issue arises. I am not aware of any Linden developer having stated that they have themselves replicated the issue....which would certainly help !

I would add that time is FAST running out on this issue. I know a number of people ( myself included ) who are simply going to leave SL...within days not weeks.......if the issue of frequent crashing is not resolved.

Also...to be perfectly honest....as this issue is a show-stopper for many, it really OUGHT to be appearing on the 'Grid Status' reports......and not tucked away in some obscure ticket that no Linden has responded to since January.

The reason I posted the information about texture processing above is because texture handling seems to be directly related to the memory leak. Three major issues very traceable:

1) It takes a single texture over 20 seconds to load (sometimes over 2 minutes).
2) Sculpties (texture-based shapes) sometimes take over 10 minutes to load.
3) A severe, constantly increasing memory leak that leads to crash... that is instantly reversed if we minimize the screen (thus clearing and restarting the texture cache? Dunno).

A couple of things are certain in this: textures are not loading as they should (the whole texture system is borked) and in over a year... Linden Lab still has not fixed the memory leak problem.

In my company, either one of those issues would have resulted in pink slips handed out and a more capable systems director hired. I feel I need to be frank here to drive the point home: any programming staff that can't get a texture to load in one second flat, that allows a memory leak to continue for over a year, that can't get simple chat right and can't get a notecard delivered to every person on a group list-- is an incompetent staff, no matter what their claimed "skilz". I don't say this as insult; I say it as standard business policy. I know LL has a lot on its plate and frankly, I wouldn't want to be one of their coders. But if you're going to be in the business-- do it right. Be professional and fix the major bugs NOW. Linden Lab keeps telling us that this is a "difficult problem and they're still working on it." My response to that: if your current coders don't have the skill to fix a system-strangling memory leak within a week, call in third-party consultants. You don't let problems like this just go on and on.

If I had run my company like that for two decades, I'd have never reached 2 decades. If these kind of things keep going on, I seriously doubt SL will continue to survive the upcoming market war. Linden Lab's paid-customer base is decreasing, not increasing. That alone should be enough to wake up the board of directors. They have a new CEO; time maybe to start cracking the whip?

All I know is that SL is frequently crashing every 5 minutes......especially for my SL partner. This is not acceptable. We are both running top of the range PCs.........4gb memory.......Geforce 8800 GT graphic card..........quad processor.....yada yada.........and good internet connections.

Now......there must be some part of 'this crashing is not acceptable' that Lindens do not comprehend !

As my boss used to say..............." we don't want excuses....we want results ! "

I am personally apalled that a Linden has not responded to this ticket since January.

LL must be aware of the business principle that it only takes a small ( 10% or so ) portion of your customer base to get disillusioned.........and in fact that disillisionment is spread way beyond that 10% in no time.

No...I don't want to slag off LL as others have done......I would much rather take a proactive approach of being critical but at the same time attempting to get a Linden to work with me on a fix.

So....a challenge to LL.....I can guarantee to replicate this issue. Is there a Linden out there who wants to arrange a time to come and see ?

Well-said. Exactly the point. Businesses don't thrive on excuses. If we can send a man to the moon, we surely ought to be able to fix a memory leak and get textures to load faster.

"No...I don't want to slag off LL as others have done......I would much rather take a proactive approach of being critical but at the same time attempting to get a Linden to work with me on a fix."

I'm glad someone else said this. I have never wanted to bash LL or be anti-LL or harass LL. Like you, the goal is to move LL to make SL better. I'm not one of those who believes that SL is essential to existence or that the world will end of SL goes offline tomorrow. But I am one that thinks SL fills a void that needs filled, so I'd like to see them do it well. LL isn't the only company in such a position; a large company called Micro$oft has the same issues-- failure to provide what the customer needs (although I'll say one thing for Micro$oft... they are Johnny-on-the-spot with bug fixes. Have to tip my hand to them on that).

BUT, these things said, I am pleased to note that either because of this thread, or other threads, LL seems to have this one on the dev table now: VWR-8503 and DEV-19402. So glad to see that. : )

(BTW, I also am aware that Qarl has been working his hiney off to bring us some really neat stuff like position-sensitive prim touching, so it's not like all LL coders are just sitting on their thumbs. Thought it was only fair to say this.) I hope someone gets this particular issue fixed yesterday.

SL has no business chewing up 1.9GB of memory. None at all.

These problems need to be fixed and NOW. Not two weeks from now, not next month, not in 3 months, but NOW.

What does this mean? DROP ALL 'NEW FEATURES' YOU THINK WE WANT/NEED AND INSTEAD CONCENTRATE ON FIXING THIS BUG. It is preposterous that you would be working on developing 'new features' when you have a BROKEN CLIENT.

Jaereth, you're exactly right, and you pur that as well as anyone could.

If I may, it might be appropriate here for me to go "RL" and get all professional here.

If I were an employer and seeing this problem happen for over a year, this would be my "pep talk" to my systems analyst:

"I know this is a tough problem. I know it's not easy to solve. But that's why you're paid the big bucks. This isn't an issue that can be ignored or tolerated. Our customers are crashing on a regular basis and we have lost 7% of our paying membership in as many months. So here's the bottom line: I don't care what you have to do. I don't care who you have to call in. This problem is to be fixed two weeks from today. I will expect that result. If that result doesn't happen, someone is going to be on the carpet explaining to me why... and I'm not going to be in the mood for excuses. You fix it, I'll take you to the most expensive restaurant in town... and I'll even pay for it."

Really, it all comes down to business. The job is either done, or it isn't. And if it isn't time to strongly consider why and what do to about it. As you said Jareth, drop everything and fix it. That's the only viable solution. If a brainstorm of the entire programming staff doesn't fix it, call in a third-party consultant who knows what they're doing... cos allowing the problem to continue is a no-go. If they need to call in ATI staff and Nvidia staff and Micro$oft consultants... DO SO. This has to be fixed, no option.

Second Life 1.21.0 (95157) Aug 26 2008 16:03:19 (Second Life Release Candidate)
Release Notes

CPU: Intel Core 2 Series Processor (1794 MHz)
Memory: 3070 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8600M GT/PCI/SSE2
OpenGL Version: 2.1.1

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17764 (Mozilla GRE version1.8.1.13_0000000000)

I installed SL at a computer with a fresh istalled WinXP SP 3, with 2 GB Ram, a brand-new upgrade of my graphic-card driver (GForce 6600) as well as the most recent drivers in my router and net-controller.

SL crached every some minutes.
I tried every version.

We must not forget: We, that we write at Jira are a minority.
Most SL avatars do not know about Jira. They just quit gaming.

And HOW MANY quit playing, we can see at the drastical fallen land prices and the drastic drop of Lindens-spent in every shop-location. Oh yes, they can push their "Lindens spent" figures. But why was land offered at 0,29 a sqm to me recently?

And again, they Lindens offer us "new features in the viewer", as it would not be more important to save the endangered whole ship.
Who needs "new skins" if the viewer crashes all the time?

Rita

I just upgraded my quad-core computer to an Nvidia 9800 GTX 512 meg graphics card. That's about as strong as a person can get in the under-$300 range. And yes, the problem with memory overruns, crashes, slow texture loading, sculpties freezing, failure of avatars to rez properly, invisible avatars... they're all still present. The primary, overriding commonality between all these issues: they are all graphics related.

I also have a laptop. Dual core, 2.6 ghz processors, 1100 mhz front side bus, also an Nvidia 9800 graphics module with 512 megs of dedicated graphics RAM and access to an additional 1.5 gigs on-board RAM (4.5 gigs total system RAM)... and yes, the problem exists there as well. So like you said, it is NOT our computers. It's the way LL is handling texture and graphics issues and networking problems.

You are right, relatively very few people post to this JIRA. Seriously, how many thousands and thousands of active SL members.... and we see the same names here over and over. We're like an extended family and you see the same people posting enough that we kinda get to know one another. Add that to the fact that the paying membership of Second Life is decreasing instead of increasing... and that should be a strong signal to Linden Lab that people are leaving SL... not by the hundreds or even thousands... but by the millions. They know that. We know that. If Second Life is going to ever hold a significant chunk of the VR entertainment market (they're not doing so yet)... LL needs to stop making excuses and apologies... and FIX long term issues such as this (as well as group chat, group notices, teleport issues, failure to rez objects, lost inventory... gah... the long-term-problem list just goes on).

I think they're getting that message; I'm actually seeing some nice things start to come out in the way of user interface (such as the clickable user names in IMS)... but the really major things, such as this memory leak, continue unresolved. And I know, from (mumblety mumble) years of professional corporate computer watchdogging... this is a problem that CAN be fixed PROMPTLY, if someone will just get off their corporate tails and make the hard decisions-- namely, tell their people to fix it, call in someone who can, or pick up their pink slips. Failure to fix is not an option. And I think posts like yours and several others above are accurately indicative of the frustration of SL customers over this problem... a problem that has gone on for YEARS now.

And btw folks, I mean... just look at this issue above: 177 votes (at this time)... and look at all the related issues!!! Geeemineee... what more does it take to drive home the fact that THIS. NEEDS. FIXED. NOW.

In a day, NO MATTER where I am or what I am doing, my computer will freeze at about every 20 minutes. If I'm unlucky, I might freeze every 5-10 minutes. And those freezes don't last for a few seconds. I've sat on one for nearly an hour and it wouldn't do anything. I have to reboot my computer manually EACH times. That's on top of all the memory leaks and crashing issues that happen every now and then.

This adds to all the minimal frustrations I had before about the game, now it's just a torture. I could just quit but I'm a RPer and I'd like to enjoy the games I play without crashing everyday MANY times a day. Fix this. Many of us spend money on this game and right now, it feels like we're being ripped off of our money and like we're waisting it when we could actually enjoy it. Fix it, easier said than done, go back to a previous version that had less issues but get rid of this s********* version, fast!

Yes, there is a basic issue here.......................but some of you will find that simply updating your graphics driver ( especially Nvidia ) resolves the crashing.

For Nvidia cards in particular, the latest version of SL uses a version of OpenGL that is not properly compatible with anything but the very latest drivers ( in the case of my Geforce 8800 GT..that's August 8th driver ). The release notes for the latest SL version should have stated it is essential to have the latest drivers......as it is. You most certainly WILL get crashing using any former driver.

Not everyone here is describing the same issue.....and for some, a driver update will fix their crashing.

And yes, I am running with the latest NVIDIA driver on my laptop. The problem reproduces nicely on an ATI based system, it too with the latest drivers.

I had to find a group of SIMs that were not affected by today's borked networking problem, but riding through those (texture rich) I could do so for two hours with no major loss of performance. There was some FPS loss at the end of the test and the working set of the viewer process shows indications of a slow but general rise in virtual memory. When I tried, earlier, the same on 1.19.1.4, the lag effects (and memory leak) appear after an hour or so but they seem to get better if I stay in the same SIM for a while (as in 5-10 minutes). With 1.20 & 1.21 the lag happens in minutes and the viewer crashes with an out of memory message (depends on the 1.20.x release), or just a crash dump with the 1.21 release.

Going back to 19.0.5 was a bit of nostalgia where distant land looks like land and not shiny false ocean (see http://jira.secondlife.com/browse/VWR-4714, unassigned).

So, this texture loading and severe memory leak bug looks to me to be a result of many mitigation attempts that have missed finding and fixing the root cause of a major memory leak that goes back to the 1.19 and perhaps late 1.18 releases. That's two years folks.

Bottom line: there's not really any reason that SL should be so graphics-power packed that it overrides standard graphics cards. It would have been totally possible to design the system to work with even lower end graphics cards (Nvida 5500, 6600 etc). The truth is, LL has pushed the graphics limits to the point that for many people, the game is unplayable.

When people have a computer that will easily play WoW, will play Quake and Unreal and most standard games on the market... then they come to SL and it borks, that tells us one thing: the folks at LL are not putting reasonable constraints on their coding. Strikes me it's like a kid in a candy jar who doesn't know when to stop... and winds up making himself sick.

i have done the uncheck VBO and uncheck Object-Object Occlusion. but here i am i load and the program size ( i live with task manager open and vm as a column) is in the 300,000 upon loading and vm is about 330,000 slightly higher. NP yet,
(Done at SL home with few scripts) but the program should not be 300,000+ so i Drop Screen to taskbar. this lowers sl program to about 50,000, but will increase and stablize at around 138,000, but vm memory has now increased to 518,000. if i decide to go somewhere with people, awesome design for example, program memory is back up to 303,000 and virtual memory is at 500,000 still. Drop screen to reduce program memory and went to 50,000 - reopen and will go up to about 130,000, but vm is still at 500,000 increasing slowly. I walk around programmem goes up again to 300,000 and vm is now at 600,000, then drop screen- goes to about 50,000 then increases upon reopen to about 130,000 again, but vm remains at 600,000. even with the drop screen the vm continues to rise untill it hits about 700,000 and i lock up, crash, etc.

I wish SL and the lindens would fix this problem, i was going to buy land , but now i am not sure until i can stay logged on without problems. If i need to run an sl program 1.19.0(5) from february in september ( and that 1.19.0(5) is really the 1.18.4 renumbered from the earlier release candidate!)

SL and the linden get on the ball! keep it going wayfinder !!

Though it crashes for several other reasons (looks like asserts are converted to crash/dumps, and I am fine with that for an RC), it appears that this release has fixed a good deal of the memory leak problems. I do not have numbers yet, but I could do my usual sail across several texture rich SIMs and survive. I have been running with this release for a few days now, so far so good.

Texture loading is still slow but that bears discussion in another jira report.

I think, Linden Lab, that you need to understand that this can't go on indefinitely. There are four reasons for this:

1.) New users are going to be turned off by the program's inability to operate for an extended period of time, and a lack of growth in any corporation is synonymous with death.
2.) Older users that drive the engine of your virtual economy are going to leave rather than waste their money on a program that is full of bugs and a company that frankly doesn't seem to give a flying fuck (I've seen people leave because you ignore them regarding very serious server-side problems with their business). Their lost economic input and premium subscription fees will equal lost revenue for you.
3.) What I presume to be your loftier ambitions of becoming a mainstream service provider to larger real world corporations are going to be thwarted when they look at your track record with the general public and the overall laxness in your software design and debugging process and decide that you are not a worthwhile investment.
4.) The client and server engines are open source now (I commend you for this). You are no longer a monopoly, but appear to operate as if you still were. Its only a matter of time before the new competitors still in their infancy (eg. OpenLife) finally mature, and the quality of customer service and software design processes becomes a critical factor that determines your life or death as a corporation.

I like Second Life. I think it has a lot of potential. But frankly, if you continue on this path of poor corporate management then your path leads to ruin.

Sad thing is, for over 3 years I've been telling LL exaclty the same things... and have been disappointed to see the same traits you describe just continue instead of improving (I'm speaking of company attitude). That attitude has lead to very poor performance, major bugs that continue for weeks, months, years, and LL seems to think those of us who say this is not professional company management are nut jobs.

As a result, the things you stated above (and that I and others have been warning LL about for ages) have come about. Instead of an increase, we've seen a 7% decrease in the paying customer base, a recent drop of 8% of the overall populace (within just a few days period of time), and the same irritating, stupid problems still going on (the one we're right in the middle of now on JIRA is the inexcusably slow texture loading process that LL has known about for ages and failed to fix. We soooo needed Windlight you know...)

It's not that eye candy isn't nice. It's that before one puts in stained glass windows, it's best to patch the foundation. You pretty much nailed it on the head Soto... these kinds of policies have eventual consequences. I see LL doing a few things now to try and catch up with the problems, but as you pointed out, it may be a case of too little too late. Unless they majorly change company policies, processes and methodologies, like you I'm afraid SL is going to be swallowed alive by the quickly approaching competition. I wrote two or three lengthy blog articles regarding this on the Elf Clan website, saying exactly what you've said above.

Like you, the only reason I'm even stating these things is because I like the creativity and environment of Second Life. But I have to admit that if a more stable platform came along, I'd have to consider it simply from an investment standpoint. I have serious concerns at this point for the future of SL... and it's because things like the subject of this JIRA are NOT being addressed and corrected.

I think using 824MB of RAM in a few hours and climbing until the system comes to a standstill is more than a little ridiculous.

The latest RC seems to be worse about texture downloads in that textures sometimes just never load if one does not move to areas that contain new textures. It is as if various downloads have timed out and whatever mechanism used to be in place to restart them is now missing.

Worse, when a texture download storm begins, the abiity to move around is seriously degraded with precipitous drops in viewer frame rates. The sense of lag is extreme. Have you folks raised the priority of the texture loading threads in this latest viewer? That's not a great idea.

Taking snapshots to document the problem is no longer feasible because the act of openign the snapshot window often hangs/crashes the viewer.

I urge the developers to run a diff on the this release and the previous and find what was broken. We're piling errors upon errors, and black box testing begins to lose utility with too many compound or cascading bugs. LInden developers, let me give yoou a personal example of the consequences of your inability to resolve these problems:

Now all my inworld products that use grab-detect to permit manipulating sliders and other controls (Such as preset lighting boards) are broken and I again face the loss of revenue from people demanding refunds. Let's see what all the unfixed SL bugs have done for me: I used to make boats but SIM hand-off failures broke them. Mainland sales tanked because the bug in which running into ban lines breaks vehicles was not fixed or even looked at; then I used to make floaters and no-sit elevators but havok4's bumpy handling of avies on moving surfaces broke them, then I used to make synthesizers but playsound bugs broke them, then I used to make lighting systems and windlight plus various other bugs broke them; ... well my multipose cushions and seats sort of work except for that recent SetPos bug/change which causes people to sit in the centroid because the setpos update to the viewer is no longer reliable.

I used to have a nice business based on entertaining or useful products. No longer. With refund demands happening every time LL breaks something, with sales tanked because people are wary to buy anything other than clothes or poseballs, I'm forced to close down my stores to end the recurring rental fees. And, I'm not into porn, sex, guns and griefer tools, which I notice seen to be doing quite well.

------------------
System Information
------------------
Time of this report: 10/6/2008, 22:00:46
Operating System: Windows Vista™ Business (6.0, Build 6001)
System Manufacturer: Dell Inc.
System Model: XPS M1330
BIOS: Phoenix ROM BIOS PLUS Version 1.10 A12
Processor: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2 CPUs), ~2.2GHz
Memory: 2046MB RAM
Windows Dir: C:\Windows
DirectX Version: DirectX 10
Card name: NVIDIA GeForce 8400M GS
Manufacturer: NVIDIA
Chip type: GeForce 8400M GS

Second Life 1.21.5 (98701) Oct 6 2008 10:27:21 (Second Life Release Candidate)
Release Notes

You are at 238094.5, 248135.8, 21.6 in DreamScape I located at sim363.agni.lindenlab.com (64.154.221.49:13001)
Second Life Server 1.24.9.98659
Release Notes

CPU: Intel Core 2 Series Processor (2194 MHz)
Memory: 2046 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8400M GS/PCI/SSE2
OpenGL Version: 2.1.2

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.18629 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 0/3442 (0.0%)

Lovely. Second Life 1.21.5 (98701) Oct 6 2008 10:27:21 (Second Life Release Candidate)

happens anyplace, anytime.

Tried the standard 1.20. It has that severe memory leak problem.

I can no longer run events. I can no longer sail, ride a floater, ride a car. I can no longer walk around too much. I can no longer dance for more than a few minutes. I can;t take snapshots because that often crashes things.

Am now finding buyer for my SIM.

I crashed with version 1.20. every 20 seconds, with 1.21 every 15 seconds.
These versions were the worst I ever saw of bad versions in a row since nearly one year.

I had stopped playing for months.
What can you "do" within 15-20 seconds?!

The above version works for me.
I log out after having played.
When did I log out the last time? In about January sometimes.

Bapien: The problems you describe are not the same I had.
So I cross fingers so much, that it works for you as well.
If we read our thread, there seem to be many different reasons for our problems.
Sometimes one suddenly said "version works" and we all others could just cry and shout "not for us".

My situation was:
GForce 6600, "memory leaks buffer overrun" or "SL just dissappears from the screen without saying anything".
Online time: some seconds. Of course there did not load much in this time neither.

This situation changed to "can play nicely again" (with 1.20.17, built 98 669.).
Crash: every some hours.

running version 1.21.6 (99587)....

One thing to keep in mind is this has been a continued issue for many previous viewers as well.

Today is a typical day for me.. I've cleared cache and restarted sl several times. I've even on occasion uninstalled and reinstalled the viewers to no avail. I know how to clear everything off the system that pertains to sl and how to do a clean install. I've written about this in support and was told to write here.

Right now both cores are pegged at 100% when I am on the SL viewer. I just recently logged in within ten minutes and have fully loaded my inventory and am only standing. My memory being used at the moment is 418,456k it will more than likely continue to rise as usual and reaches upwards of 1.5- 1.9 gigs. My system has about 3 gigs of ram.

I've tried various hints and tips throughout the past viewers to no avail. I've even set affinity to no avail as It was never suggested which core to use its just pretty much always been advised that there isn't a way to tell which is best but to just try and see which works better. Well neither really works better the problem still continues. Sometimes it fixes the problem temporarily but most times it doesn't do much good.

I'm really finding it difficult to understand why these types of memory leaking issues aren't being fixed after so many releases.

What can I do besides the obvious and just log out for good.

The crash on PNG snapshot bug seems fixed, but now opening any window (edit script, edit object, open communications, etc.) has a decent chance to cause an app crash. I had obligations to run two sailing events and I crashed my way through them. Well,l I'm done doing those kinds of events for the foreseeable future. It is also very difficult to build anything. Between the crashes while manipulating variouseditng windows and the slow texture loads, my efficiency is tanked.

And if that isn't bad enough, I finally figured out where the extreme FPS drop and lag is arising. These latest releases seem to have made flexi-prim rendering much slower and overhead laden. I don't have this lag problem with 1.19. To test this conjecture, I created a huge opaque 50m dome. I went to a flexi-rich area, noticed the intense lag, rezzed this dome around me and watched the lag do away. Then I derezzed the dome and watched the intense lag return.

Finally, you guys again broke flexi rendering. Now if I step back more that 63m from a flexi object, the flexi-prims straighten out. Now that's a wonderful PG destroyer to see those flexi-prim skirts lift up and expose people.

Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release)
Release Notes

You are at 280847.4, 262476.6, 33.1 in Quantum Acres located at sim5789.agni.lindenlab.com (8.2.35.91:13002)
Second Life Server 1.24.9.98659
Release Notes

CPU: Intel Core 2 Series Processor (2400 MHz)
Memory: 2048 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9600 GT/PCI/SSE2
OpenGL Version: 2.1.2

Every once in a while it seems I will be able to last for 15 minutes, or possibly half an hour. At other times, the memory fills up so quickly that I seem to crash within moments of logging in. More and more often the crashes are happening quickly and often, and on a growing number of occasions it has prevented me from doing anything productive in SL.

Second Life 1.22.10 (112620) Feb 20 2009 17:25:43 (Second Life Release Candidate)
Release Notes

You are at 234556.8, 277772.3, 1001.6 in Desperation Andromeda located at sim5800.agni.lindenlab.com (8.2.35.102:13000)
Second Life Server 1.25.5.109327
Release Notes

CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3166 MHz)
Memory: 4090 MB
OS Version: Microsoft Windows Vista (Build 6000)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 9800 GT/PCI/SSE2
OpenGL Version: 2.1.2

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.22145 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 7/8540 (0.1%)

Please see these articles in Knowledge Base How can I improve performance ? and How do I check for packet loss (network lag)?

This article will show you how to get detailed information about the performance of your computer and the Second Life world Statistics Bar Guide

If this is still an issue please Submit a Ticket with Support for account-specific help

Thank you : )