|
|
|
[
Permlink
| « Hide
]
Maggie Darwin added a comment - 06/Sep/08 09:23 AM
Still broken in RC1
Hi Maggie! Have you tried updating your drivers?
@Alexa: Have you seen the total freaking mess that SL Viewer support is for nVidia drivers lately?
Perhaps you can prod someone in LL to comment on I had this too in RC0.
It's less in RC1 and RC2 but still there. My nVidia drivers are current as August something. I have a GeForce7600GS WinXP SP3 Update: the memory leak is faster or slower at different places. I can stay on all day in most sims. But there's a few places where I'll crash several times in a few hours. On sim in particular is a rather uneventful openspace sim, not really sure why it was bad there. Unfortunately having a RL job prevents me from making it to triages.
from http://wiki.secondlife.com/wiki/Bug_triage/2008-09-17/Transcript [15:14] Bridie Linden: # VWR-8841[c SpaceNav flycam may be involved...not implicitly but because it makes rapid camera movement easier and more common. It's possible that being on nVidia may be part of this to. ah, no. I was commenting on the previous issue we'd been discussing. QA has also tried to repro several of the memory usage issues, but we haven't been able to repro them yet either.
If the leaks are different in different places, can someone give us specifics as to where this seems to be the worst? Also, log files help and of course, environment for each person seeing this. Thanks! Seems worse in texture-rich environments; try cheap shopping malls crowded with many small vendors that you've never been to before so the textures aren't cached. Move your camera in them rapidly; orbiting in particular. Definately seems SMP related, so work that camera hard on a Core 2 Quad. Keep an eye on your virtual size as reported by Process Exporer; when it exceeds 2 gig you'll know you'll be going bye-bye soon.
You're not going to get a solid repro because there are too many variables (SMP dispatching, UDP network latencies, texture cacheing). Is there some reason the crash dumps are not sending you logs? Product
Second Life Problem Date Status Problem signature Product Problem Date Status Problem signature Product Problem Date Status Problem signature There is a metric buttload of errors in this log before the viewer finally crashdumped with over 2gig of memory allocated.
The death rattle is: 2008-09-20T14:41:07Z WARNING: LLAppViewer::mainLoop: Bad memory allocation in LLAppViewer::mainLoop()! which was preceded by hundreds of 2008-09-20T14:41:06Z WARNING: LLImageGL::readBackRaw: GL Error happens before reading back texture. Error code: 1285 and 2008-09-20T14:40:56Z INFO: LLSDXMLParser::Impl::parse: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:Upstream error: A clue that the texture cache is corrupted in memory may be: 2008-09-20T14:40:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: fafd5543-d106-4bba-3c44-281429dcda5b Discard: 0 @alexa: Is the log file not sent with crashdumps?
Out of curiosity, I'd like somebody who regularly has the massive memory usage and crash to try the following:
set the client cache to 500mb, and set texture memory to 64mb. Then watch memory usage over the course of a few hours. @Chalice- I'll give that a try.
By the way, I've been having pretty good success inducing this by going to the Ahern Welcome Area and camming around a lot with a Space Nav. Just reproduced it again with 1.21.3
Repro: Go to Ahern Welcome Area (always has many avs at a sim corner) . Cam around rapidly (orbiting rapidly with a SpaceNav is good).Watch as memory climbs above 2gig. Then crashdump happens. Another repro:
TP to Burning Life and fly towards the center of the Playa at about 80m altitude. Just crashed again at Burning Life.
I'm starting to believe this has less to do with texture caching and more to do with how many avis are nearby.
Still present in RC 5.
The "Animated Flosstown" section of Fishers Rest region is a good place to see this happen too. i'm not seeing the crash but the frame rate i am seeing in RC5, and memory usage is off also, after i don't move 4 a bit the fps go's down to 2or 3 fps, not all the time but more than it should happen on all the fps issues. or when i run it will go down to 6 to 8 fps, flying down can do this also as i have a spinning fly down, i know 95% is not the sim as i have another av nxt 2 that av and will show what i take 4 a normal fps, 35 to 40 fps,sometimes it will recover but most times not, another thing i'm having, don't know if it's related but the longer i'm in world the "freeze" between opening a new inventory window is longer and longer finally turning into a black screen with a "not responding" error msg that has crashed my client in the past as i said i don't know if it by product of the fps thing, the memory thing i get is it drops down 2 about 39/40%,or lower, free and might recover some when i minimize but most often not, when i try 2 force a bit 2 recover, everything freezes up when i bring the window back up and things will move after a bit but not before most of what i gained is used up again, with the amount of ram i have i would'nt think memory would get eaten up that much, i could b wrong. i do expect larger memory use with 2 av's on but not as fast a drop off like i'm seeing, 1 usually run at least 2 avs 90% of the time i'm in so most of the time i can tell when things r not right as i have been doing this 4 quite a while with 2 or more in world. oh i also have things set to"purge" so my cash dumps every time i log in.
Second Life 1.21.5 (98701) Oct 6 2008 10:27:21 (Second Life Release Candidate) You are at 201435.4, 265773.4, 623.8 in The Wastelands located at sim5746.agni.lindenlab.com (8.2.35.48:13001) CPU: Intel Core 2 Series Processor (2399 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 @chalice:
With texture memory set all the way down to 64MB the crash does seem to take substantially longer to happen. With 512mb a rail trip from Tulpitree crashed shortly after Neumogen. With 64mb I got all the way to Crumbi still below 1.93 GB vmem before I got brave and turned on the Map display. The crash happened very shortly after turning on the map....before all the map textures loaded, in fact . What's the theory behind your recommendation? with texture memory set to 64mb
Uploaded a PrintScreen of WindowsXP task manager while memory usage climbed in a sim with little action and only 2 avatars including myself (FairChang Remolino).
("Memory Leak in 1.21.RC4.bmp") Still failing on 1.21.6 final with default texture mem of 640
Agreed, this is still a major problem in 1.21.6.
Nothing was fixed. I had to revert to 1.20.17 in order to remove those crashes. It works much more stable for me. 1.21.6 also performs much slower on my 9800GT card. In crowdy places there is usually 5fps and it freezes while rotating camera. On 1.20.17 it gets to 25-30fps and rotating camera isnt such a pain though it could use more of my graphics card. I had GeForce 8600GTS that worked much smoother on 163.75 driver. Now im on 175.16 driver that is quite slow but at least does not have texture bug http://jira.secondlife.com/browse/VWR-7957
CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (3333 MHz) I have seen this spike in memory usage, followed by an out-of-memory crash on my system too.
I have nVidia 9800, with 512Mb in it. The computer is a quad core Intel Core2, with 8G of ram, Vista Home Premium 64 (with SP1) etc etc When I installed SL on this new machine, it decided to set my texture memory (prefs/graphics/hardware) to 2G, waaaay over the 512M the card actually has. SL would slow, then crash. Setting the texture memory in SL to 512M solved this issue completely for me. Mine is currently set to 512 on a 640 mb 8800 GTS card.
I should note that while the Vmem is always at 2 gig or above, the crash does not issue a message indicating that memory is exhausted. It just puts the crash alert box up, no reason is given. So, is this still in the "if there's a memory leak you have to tell us how to reliably reproduce it" pile?
I admit I'm growing weary of having to check the viewer VSIZE when I start noticing frame rate going down, and relogging of it's more than about 1.8 gig, because that means The End Is Near.
Often the deteriorating frame rate when orbiting my cam is a clue...other times displaying a profile, launching the map, or starting a search pushes me over the edge without warning. Most reliable repro to date:
Use a multicore CPU, preferably quad, on a high-speed connection: Ours is 15mbps fiber Go to http://slurl.com/secondlife/Atropos/149/146/39 Flycam though the "Need4Speed" for a minute or three, This location has objects playing audio, many many densely packed campers (24) and about a zillion textures. 2009-01-01T03:55:53Z INFO: LLStartUp::setStartupState: Startup state changing from STATE_LOGIN_SHOW to STATE_LOGIN_WAIT... Death rattle: 2009-01-01T03:58:01Z INFO: display_stats: FPS: 16.60 Second Life 1.22.4 (106127) Dec 16 2008 12:22:22 (Second Life Release Candidate) You are at 257172.9, 262289.8, 39.4 in Atropos located at sim5871.agni.lindenlab.com (8.2.35.173:13000) CPU: Intel Core 2 Series Processor (2399 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 This repros really well.
Well, I mean..not that it's good... 2009-01-04T18:55:39Z INFO: display_stats: FPS: 11.62 Still broken in RC 5. Reproed easily using the method described above.
Two hundred and seventy two GL1285 errors issued just before the crash. Also of possible interest: 2009-01-07T23:14:58Z WARNING: LLViewerImage::setIsMissingAsset: d8d3bb3d-b3be-1953-8d05-132a55f9bc0f: Marking image as missing The 1285s started at 2009-01-07T23:15:23Z 2009-01-07T23:15:34Z WARNING: LLAudioChannelFMOD::play: LLAudioChannelFMOD::play error: An invalid parameter was passed to this function 2009-01-07T23:15:41Z WARNING: LLAudioChannelFMOD::play: Playing without a channelID, aborting ... 2009-01-07T23:15:44Z WARNING: LLImageGL::setSize: texture size is big: width: 2048 height: 64 Hey guys, we are working on this issue. As a temporary measure, goto "preferences -> graphics tab -> hardware options" to set the texture memory to be 256MB if the current number is above that. Try it to see if it helps.
Haven't been able to crash it at Need4Speed yet at 256mb, and I've been camming through there for twenty minutes
Texture performance is kind of stinky, but at least I'm not crashing This severely needs fixing, you can't tell your customers to buy hotrod vidcards and then not support them. I hope
If there's a bug in nVidia driivers, please give us the nVidia bug numbers so we can press them for a fix. I am updating the Description to include Maggie Darwin's reliable repro steps.
Um...the single log record there under "OBSERVE" isn't significant, is it?
Cannot repro with 1.22RC9 under XP, running on ultra graphics settings. Memory usage is stable at 490MB, even after 90 minutes of being in the sim.
You know, I think this is more deserving of "fixed" than "cannot reproduce". It sure as heck was reproducible, and I worked hard with Lindenfolk to help them find the circumstances that reproduced it.
If it can't be reproduced now, it's because it was fixed (or at least the code was shuffled enough that the symptoms are different). My client crashes a lot, more so if I'm trying to do some building, but it's not restricted to that.
I've tried everything I can think of from drivers, different clients and graphical settings. Second Life 1.22.9 (110075) Feb 10 2009 12:43:24 (Second Life Release Candidate) You are at 232785.1, 257357.6, 22.0 in Ryder Manor Isle located at sim957.agni.lindenlab.com (8.4.129.107:12035) CPU: Intel Pentium 4 Northwood (2992 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 Well, 1.22.9 isn't crash-free, that's for certain. But you might want to make a separate JIRA for yours.
1.22.11 isn't leakproof either...for some reason especially since server 1.26 happened, it seems. Attaching new log/debug/memory
This or something very similar seems to be back in 1.23 RC 3
Still happening in 1.23.4
Does this help? 2009-06-13T13:46:46Z INFO: viewer_windows_exception_handler: Entering Windows Exception Handler... Since we're still seeing crashes with the same core symptom: quad core box leaks memory up to 2 gig vmem and then falls over, it seems unlikely this is "fix pending"
I was getting this really bad in all the 1.21 renditions, but it was fixed in 1.22 and 1.23 is even better so far.
I notice Maggie is running vista I have been using both WindowsXP standard and WindowsXP SP3. CPU: AMD (Unknown model) (2004 MHz) <-- (Single core AMD64) Looking forward to nekolili's full configuration, especially how many cores sie is running.
Meanwhile, we seem to have a nomenclature problem: How can a bug be "fixed" in 1.22 and "better" in 1.23? What's better than fixed? I don't consider a bug to be fixed until it doesn't happen anymore. Sorry, by fixed I meant my RAM usage wasn't ballooning with SL in 1.22 and not crashing every few hours. And by better I meant 1.23 seems faster and more stable than 1.22, as before SL 1.21 would eventually get all spazzy as RAM filled.
Well, of course it's not RAM that's filling as such. It's the address space. I've got oodles of RAM, but on a 32 bit OS you only get so much per address space. There's more on Vista 32 than XP 32, but when you're leaking eventually it runs out....and 2 gig is it.
I think SLV leaks more when stressed on a quad-core simply because there's more opportunities to tickle it in places where it isn't threadsafe, especially if you use flycam a lot. Still leaky on multicores. I guess this is still considered "normal".
If LL wanted to fix the myriad problems that THEY created in the viewer, it would be fixed...
Incompetence, greed and lies are why this issue is still open. 99% of the people at the Lab are hardworking, honest, smart and devoted to doing a good job for all of us. It sucks that the ones making policy aren't among them. Good luck Maggie, you fought the good fight, I'll always appreciate and respect the work you and many others have done here. Ciao Well, I won't minimize the difficulty of writing un-threadsafe code. I've done it myself, even in modern languages. And the only thing that's more difficult than writing it safe in the first place is finding the unsafe parts once it's already written, especially by somebody else.
When everybody was on a much slower chip with only one core this wasn't so much of a problem. Now it is. I'm trying to reset the fix version because obviously 1.22 doesn't fix it. But I select "unknown" and it doesn;t change.
trying again to reset "fix version" This is still happening.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Major
Memory usage goes to 2 gig, graphics frame rate tanks, crash dump taken, viewer not responding
)