This would help to know which viewer you are using and to see if there are any specs that you have in common with other JIRA reporters

This memory leak problem is extensive. It has been reported by numerous people and is recognized as existing by Linden Lab. I'm reporting nothing new with one exception: when the computer freezes, what it sometimes appears to be doing is dumping SL memory, after which it resumes. That's not always the case, but I've noticed this several times now. As seen above, my computer rocks. Should be able to handle anything SL throws at it. I don't lag all the time like many people with lesser systems... but when I do lag it's a doozy.

Interesting that you are seeing the freezes on the Official Viewer.

Do you still get them if you turn down your graphics in SL Preferences (and yes I know, with your graphics card, you shouldn't need to ? Also, Nvidia have some very specific instructions about what to do when you update their drivers, I wonder what difference it does make if you don't remove the old driver first or turn off virus protection when you are installing?

Anyway thank you very much for posting, I too have this problem but the latest RC 1.20.6 and turning down the graphics in Preferences seem to have minimised it. I hope all this information will help LL find the cause

Yes, I've worked as a computer pro for many years, so when I installed the Nvidia I made sure it was by the book. I had my system pro-tech built from scratch and oversaw the work myself.

I understand what you're saying about the graphics, but I have this thing: with a $2000 computer system, one of the top graphics cards on the market, and Linden Lab charging our group $700 a month for 2 sims... I don't believe I should have to turn down my graphics to accomodate LL glitches. IMO... they should fix the glitches so the system works. : )

I'm reporting a severe memory leak and subsequent memory dump that freezes the program. The three issues sited all relate to graphics problems. I don't believe they pertain to this issue.

This is a client-software-based memory leak, one that is well-known to many SL users. I'm reporting on a previously unnoticed aspect of that memory leak... that of the system freezing while apparently memory is being dumped. In this particular case, memory started at about 900 megs and counted down to 450. I could watch it visibly dump on the Windows Task Manager screen.

So a lot of the freezes people are experiencing could be due to this memory leak and dump glitch. I understand that the other three issues are regarding system freezes on systems that use Nvidia drivers... but that's not the symptoms reported here. My screen doesn't go blank or black. Everything looks just fine. It just freezes. Since the 8800 graphics card containes its own half-gig of on-board memory, unless LL is doing something really flaky and non-standard (which I wouldn't doubt at this point)... this issue isn't graphics card related. It's affecting system RAM.

I have 4 gigs of RAM (3 of which are used in XP). So I have plenty of system memory to handle anything. But when SL gets above about 450 megs of RAM use (which really, shouldn't even be that high, considering it starts out using around 50 or so)... it begins lagging and glitching. At 900 megs to 1.2 gigs, it crashes. So apparently there is a severe client software memory leak that causes SL to bog down.

This could in fact, be a major source of system lag (aside from the increasing number of reports of sim TD and FPS dropping through the floor-- reported by my stats tracker).

With similar machine specs I agree with you that you shouldn't need to turn things down. FWIW, though, with a rig only slightly slower than yours, and with graphics set to their lowest settings, I am still getting a similar crash. Actually, looking at specs it seems we probably have the same quad core CPU. What's slower here is probably the fact that I'm running Vista at present. It might be that the machine is TOO fast for the client. After all, on a quiet sim at low setting I'm getting a supposed framerate of around 90 fps when set to the lowest auto settings in 1.20.6.

My crashes on this rig could also be the usual driver instabilities while NVIDIA plays catch up with its more recent cards and the systems that can run them.

Specs:

Second Life 1.20.6 (86925) May 6 2008 20:43:54 (Second Life Release Candidate)

You are at 286240.8, 265509.9, 102.6 in Huineng located at sim5839.agni.lindenlab.com (8.2.35.141:12035)
Second Life Server 1.21.1.87495

CPU: Intel Core 2 Series Processor (2399 MHz)
Memory: 4095 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8500 GT/PCI/SSE2
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.15247 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 0/2693 (0.0%)

That indicates, as I mentioned to Ellla, this is not a graphics issue. Has nothing to do with Nvidia drivers; it has to do with SL client software memory leak. While conceivably it could be a graphics driver memory leak, such is very unlikely as it seems to affect systems not only cross-graphics card (Nvidia and
ATI alike) but also cross-platform (Mac and Linux as well).

There is an issue with Nvidia drivers on different cards and different computer set ups. The more information we, as residents, can give the developers, the better they will be able to understand the issue.

But I completely accept that there is another issue of high memory use, which you are reporting here. This seems to be affecting some residents but not all and with no recognisable pattern ... at the moment.

Let's hope that the information that is in various JIRA issues can be used to find a solution.

To check on your system (if you have Windows).

Open the Task Manger (ctrl alt Del). Click the PROCESSES tab.

Load Second Life.

Once Second Life loads, look at the memory used by the system. That should be standard operating memory.

Play Second Life a while, and watch that memory figure. Does it climb? Does it keep climbing?

When it climbs from about 85 megs to well over half a gig... that's a memory leak. It should be immediately apparent, and dramatic in scope. It's a pretty serious leak that often results in SL swallowing down over a gig of RAM (at which point it crashes just about every time, and is continuing to climb).

(in my particular case it went from 85 megs to about 371 megs in 3 minute's time).

You can get a build of his client from his blog:
http://nicholaz-beresford.blogspot.com/
http://www.blueflash.cc/users/nicholaz/EyeCandy/ <--- the files are here

That also explains why the system freezes. If it's collecting textures in RAM, suddenly deciding those textures aren't needed and dumping them all at once... that would result in severe freezes. That's very poor software design and needs to be addressed, for sure.

Glad to hear the memory leak is recognized and being worked on. Problem has existed for at least a year now. One wonders when the fix is going to be coming about. If anything is a "showstopper"... a severe memory leak would be it.

My question is however, why is Nicholaz working on it instead of Linden Lab?

Re: why is Nicholaz working on it? Thanks to the open source initiative – also Nicholaz happens to have been the one who found and squashed many memory leaks. Namely he's good at finding them, while someone at LL seems to be just as good at creating them (and at providing very ineffective garbage collection).

I don't know why I took so long to do it, but I just installed N's EC-f patched viewer. While it runs better in many respects than the release it piggybacks, at least my first few sessions suggest that pretty much the same pattern of endless RAM gobbling takes place in his version as in the release. 1.19.whatever., I mean.

This release being the more or less mandatory WL version, this leads me to suspect that the biggest leaks are somehow related to WL. That is NOT to say that I think they are necessarily graphics card issues or related to any particular graphics drivers or other suspected culprits. I see, though from Strife's note that perhaps I just haven't installed the necessary patches to Eye Candy?

I want to emphasize that I'm not finding fault with Linden Lab here. Opening viewer source to the wider community was a very good choice, in light of LL's persistent difficulties with development and also just in the nature of programming – that in a top down model of programmer management, the priority is keeping your job, not finding and squashing the most bugs. No matter how many hirelings LL might afford to put on the task as an internal effort, there's likely to be all the typical instances where one person knows very well where a problem is, but since she made the problem in the first place, she's afraid to get fired if she comes clean.

Or, he is operating in an area beyond his actual competence, and bluffing his way through the working day, with no concept of how something he did a year or two ago is bringing the thing to its knees. He might not even be working for LL any more.

Open source initiatives offer at least one partial antidote to the toxic mix of human nature and a machine's stubborn literalness in following the instructions given it, no matter how daft those instructions might seem if they were translated into precise but common English.

Anyway – to continue the saga: the 1.20.7 RC appears to be significantly more bullet proof that past iterations (not looking at such bugs as the business with money-related hovertext balloons. The big leak is still there, but at least the viewer remains stable for session that can last several hours. At least that's so for me. But I also have Vista SP1, and the 13 May (or later?) NVIDIA drivers.

The point I was making is why is Nicholaus addressing these issues <i> instead of Linden Lab </i> ?

Or maybe, as you've pointed out, LL is trying to address it, but the code is (possibly) so garbled and poorly documented that no one has the skillz to fix it.

It could be too, that as with many such problems, memory leaks are really difficult to trace down. They could come from anywhere. (But to tell the truth, coders who know their stuff know where the leaks are coming from and know how to fix them. Those who don't, as you mentioned, are incompetent and just trying to hold down their job. Can't really fault a person for trying to keep a job.)

Anyway, point is, this is Linden Lab's job, not Nicholaus. Can't expect every user on SL to download and install Nicholaus' fix. Can expect LL to pay attention and make use of such a free asset. Or maybe... hire the guy and set him to work debugging. Sounds like he's more on-the-ball than their in-housers.

I also recognize that LL would probably not be considered as acting responsibly if they were to expose every user to "fixes" that they had not reviewed and tested fairly thoroughly.

Not being privy to the internal process or just why LL acts as they do, it's probably best if I resist the impulse to speculate on why Nicholaz's fixes have a better reputation among many users than the release versions have. As with all software, you essentially use it at your own risk.

And, fwiw, the creeping gobblement of memory does proceed unchecked (well it may have slowed down some) in RC 1.20.8. But it is stable enough to use for several hours without expecting a heap crash at any moment. Likewise, Nicz' EC edition – the one that incorporates WL and piggybacks the 1.19 release version (I think?) – seems to share most of the same memory footprintage as the release viewer does.

WL is inherently a memory pig, it seems – not that this should be a surprise.

Regarding patches: I never use 3rd party patches. Because then if something goes wrong... who is it, LL or the patcher?

I noticed something today. My system crashed again, as per above symptoms. Only this time, I had reduced my texture cache to 1/2 gig. That should mean (according to claims) that my total computer memory use is that required by SL itself (about 35 to 80 megs? hard to tell) and the texture cache. 600 megs max.

The memory use at the time of the crash was 828 megs.

Memory leak.

VWR-6733 deals with Nvidia graphics card problems resulting in blackout screens, graphics problems and crashes.

This JIRA report is in regard to a severe memory leak in the SL system and accompanying memory dumps (which seem to occur at random intervals).

While there MAY be a relationship to Nvidia drivers, the SL memory leak is reported system wide. In addition, Nvidia just recently came out with new drivers-- and this problem was not resolved. So while it's not impossible the memory leak has to do with Nvidia drivers... it is doubtful, especially since most Nvidia cards access only their own internal memory and not system memory.

Reopening this as a memory leak issue as opposed to a graphics compatibility issue.

Also curious what it means "has been imported"?