|
|
|
Same on the Mac, application runs for about 20 minutes until it finally only crawls and all basic tasks fail.
Mac PPC G5, 2x2 Gig observations made before running SL, using performance monitor.
CPU usage: Max 5% After startup of SL CPU usage: around 55 - 60% And steadily rose to SL crashed approx 1hr after startup. CPU and memory usage returned to pre-startup values. Happens on my computer, too. I can go to 1 gig in an hour. I am NOT taking pictures and not changing sims that often.
You are at 260777.5, 252428.7, 142.5 in Steiger located at sim5828.agni.lindenlab.com (8.2.35.130:13001) CPU: Intel Pentium 4 (Unknown model) (3200 MHz) Can you tell us what you were doing when you this occured. Also, if you can get it to happen more quickly, that'd be a big help. We are prioritizing leaks according to how fast the leak occurs. (I know it's not optimal and i'm sorry).
On my system, it appears that when I load additional textures, the size of the foot print grows (as measured by TaskTool).
This happens when I teleport, and when I take pictures. But it is happening all the time, even when I sit still. It appears to grab memory and not let most of it go. – Hmmmm.... I'd always assumed ti was textures. I'll keep looking. This ticket is now identified as resolved, however the Quad HP is still having issues and crashes about every 2-3 hours, what was the corrective action? As the creator of this ticket, why would I not receive some type of notification of the fix action, prior to the ticket be changed to resolved?
What was the fix action? Can you send me an in-world IM or an IM to Wheemzel DeCuir so she can apply the necessary fix action? Thank you. BengalTiger Writer If this issue has been resolved, what was the fix action and why are we still having the issues? Please provide additional resolution information.
As has been noted before, while it is a memory leak it is not the same one as
As for speeding up, the most recent crash occurred while logged into one region (Huineng) for all of the session, hanging out in a very low prim sku platform, running Tiny Empires for several hours at off peak hours. Final memory usage seen in Task Manager was well over 1 Gig, while the session started at under 200MB. Will screen cap TM next time I report this assuming I can identify the proper Jira issue. This seems to be a leak that probably is common across many versions of Windows, and the error box is something I've only seen in the most recent 2 or 3 releases and generations of RC since about 1.19.5 or so..? Sys Info from a current session: Second Life 1.20.6 (86925) May 6 2008 20:43:54 (Second Life Release Candidate) You are at 286296.8, 265533.6, 92.7 in Huineng located at sim5839.agni.lindenlab.com (8.2.35.141:12035) CPU: Intel Core 2 Series Processor (2399 MHz) If you can detail of offer a template for use with Vista's performance monitor, focused on the data that would help identify this bug I'd be glad to try to run it and post results. final error box. there's also another one that shows up before this offering to retry, abort or ignore. Abort is the only option that goes anywhere.
Crashed last night because system ran out of memory.
Here's my specs: Compaq/HP Was inside my sim all the time moving some stuff I build a few days earlier (so no large quantities of new textures). SL crashed when it used up about the same amount of memory as Azadine Umarov initially reported (1,454,852 K). I did get a warning window asking me to free up memory elsewhere, but as there was none available, pressing Abort/Omit lead to an inevitable SL program termination. I'm seeing this also, setting the draw distance to maximum and using the camera (or ideally flycam) to move around uses up memory very rapidly. On my system, when it reaches 1.6 GB used I start getting the smartheap memory error. If I turn on the console display, for each time the smartheap dialog comes up I get a corresponding error loading texture. If I continue to ignore the error, I will start to see the effects in the viewer as textures fail to update until the majority of the view goes black and ultimately the viewer crashes.
I can reproduce this at will. Varying the draw distance will buy you more time as fewer textures load, a view distance of 64 will buy you 3-4 hours or so if you're conservative on moving the camera around. If I had to guess, I'd say the viewer isn't clearing texture cache memory and keeps loading it up until it runs out. I am running Microsoft Vista 64-Bit and my specs are as follows.... Second Life 1.20.10 (89467) Jun 10 2008 18:17:42 (Second Life Release Candidate) You are at 261347.5, 251455.1, 4001.4 in Agamok located at sim5381.agni.lindenlab.com (8.2.33.128:12035) CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2494 MHz) This happened to me for the first time last week. since then I have been getting the mem smartheap box every day. Today was the worse with the viewer running less than 30 minutes before my memory ran out, and that was 500m up working on my build platform. I did have my texture organizer open and was using it to find the nessacessy textures i wanted but hardly anything else in world was in my draw distance which i normally have set to 320m
I too think its texture related. Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release) You are at 172535.0, 288241.8, 22.6 in Kon Tiki Eastern located at sim2356.agni.lindenlab.com (216.82.17.107:12035) CPU: AMD (Unknown model) (2814 MHz) This behavior had virtually disappeared for me under RC 1.20.10 until it seemed to re-assert itself in just about every session on 24 Jun 08 (and possibly 23 June as well? I was managing to run some very long sessions without this or any other crash for several weeks. (Configuration has not changed, though there may have been some Vista updates that were involved.) One factor that might point to a repro is that some of the old crashes seemed to happen faster when I was running little besides an SL viewer. However, the latest crash did happen while I was running Firefox in a fairly low memory usage session.
The heap crashes that have re-emerged are, as yet, not that fast to appear, though some have come in sessions of less than 2 or 3 hours. I'm also wondering if a recent server update may be at fault, as at least one script I used heavily in world (the commercial edition of LoopRez) also seemed to show some oddness in how it executed. This I can't really confirm with much confidence, though, as I had not used that script for quite some time before seeing yesterday's oddness. Several (but not all) heap crashes also took place within seconds of sending group IMs to groups that were already getting very laggy. Have noticed very slow intial loading for many groups in this same window as the returned crashes. Also, it seems that frequently in some of the larger groups (200 members + ?) I've been able to post IMs for several minutes without incident, but start getting failure errors (usually with the IM appearing in group seconds after the fail warning) after sending several IMs in fairly fast succession – especially likely to fail when the IM is longer than a few words. Of course all these could be unrelated, but they do seem to be phenomena that have become common and very apparent within roughly the same window of time, namely, worrsening over the last few days since about 22 or 23 June. I've also been "bouncing" between viewer – and seeing the heap crash in all of them, I think. The main viewers used in this window have been the current release version, RC 1.20.10 and Nicz EC viewer. Well, the new release candidate has fixed some of the issues, but I was finally able to crash it using my usual methods of raising up the draw distance and flying around loading textures until I crashed. I did notice the memory usage actually going down some which it never did before. Had the console going the whole time, I'm hoping that gave the crash report a little extra info, in the past it seemed like having it on caused more to be logged in the logs when I looked at them.
I did something different this time, that I hadn't before, and that's watched the memory on SLVoice.exe as well. I noticed that as I flew around the grid and it kept reconnecting to voice, the memory usage went up each time. Looks like there's a little memory leak there, I thought I'd mention since it could be behind any voice issues that might be on the books here. Here's the tail end of my log up to the point of the crash.....(I saved the entire log directory if the info might be of use?) 2008-06-26T04:46:54Z INFO: LLCircuitData::checkPacketInID: packet_out_of_order - got packet 1287 expecting 1036 from 8.2.34.24:13011 This started for me with RC 1.20.11
After quite a long period of time logged in (maybe 5+ hours) XP exceeds 2.4GBs of memory and asks for RETRY or ABORT of Viewer. (ABORT being the only option that "works") I have been logged on for 5+ hours many times before but NEVER had a memory leak where memory-used exceeds 1.5GBs. Would be nice if the Viewer could constructively use my 2.5 GBs of memory available, but XP has never exceeded 1.5GBs of usage till now. PS My FPS has been cut in RC 1.20.11 from around 5-6 to 3 on average w 128 DRAW DISTANCE. My old (and current) pentium 2.4ghz and my 512mb Radeon ATI 1600 card suffered similar cutting in half of FPS when 1.18 came along . DEAD IN WATER NOW . Oh and I'm crashing fairly frequently - no pattern that I noticed causing it. Could be anywhere doing anything (or even doing nothing) I used to very rarely crash - before 1.20.8, or so . And please fix the CAMERA. I shouild be able to pan and stay focused on the ALT-click object - never jump away from it as irotate camera around it, but thats what happens way too often.. Memory leak seems to be consistant with Main Release. I dont think its only a viewer releated issue.
Possibly a Sim/Viewer combination causing the memory leak. This issue seems to be related to the number of avatars that come by. I can sit in a nearly empty sim almost all day and not go past 400-500k mem used. If I'm in a sim where many avatars are passing by, I've seen my memory usage spike up as high as 900k in about 15 minutes before I restarted the viewer. Also I've found that minimizing the viewer and maximizing it once more for some reason reduces the amount of mem being used, though the amount of Vmem usage stays the same.
I had to shut down yesterday with a out of memory error. Looking at task manager SecondLive.exe was using 1,579,476k. So this is a problem with the current production version of the viewer also.
My friend on SL has to reboot her viewer every 20-30 mins with this memory problem. She is using a XP machine with 2GB Ram. She is running the v1.19 viewer also. I am running with 2 graphic cards and monitors. For some reason the Help/About only reports the 2nd graphics card. I was using the main monitor which uses the 1st graphics card. It is a GeForce 8800 GTS 320mb Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release) CPU: Intel Core 2 Series Processor (2400 MHz) Still a problem with 1.20.14
Virtual size as reported by process explorer grows until it's just under 2 gig, then it's all over. I concur that it feels very much like texture cache management; texture rich environments seem to accelerate the failure. Second Life 1.20.14 (92115) Jul 14 2008 15:20:29 (Second Life Release Candidate) CPU: Intel Core 2 Series Processor (2399 MHz) Same problem here under 1.20.14 (92115) Release Candidate as well as the production viewer.
CPU: Intel Core 2 Series Processor (3599 Mhz) (Quadcore) I agree that it seems to be somehow related to how many people are in vincity. When i am building alone on my sky-platform the error only occurs after multiple hours. Trying to attend an event with many people i can watch memory consumption increase at almost 1MB per second. happened to me.
versions: 1.20.14, 1.20.15 CPU: AMD (Unknown model) (2211 MHz) My system is a 2GB Core Duo 2, Win XP Pro SP3, ATI Mobility Radeon X1900 256MB, running SL 1.19. I am getting this SmartHeap Error msg as well. FWIW, the first time I saw it was while walking the RFL track yesterday.
BewareHax:
Well, it's virtual memory it's run out of, not RAM. So what other apps need isn't an issue here either. But you're right that not releasing memory is the issue...and that's what cache management is. It's worrying that the folks having troube with this all seem to be running multicore chips; thread/process safety issues can be hard to track down. I got a BAD_MEM_PTR error yesterday...and I find it disturbing that neither of these failure modes is sending a dump back to LL. Nor are the crashes we get when doing audio. Ditto here. No particular sim - can happen any time. Although I've only had my computer for a couple of weeks, I didn't see this happening until 5 days ago. I thought maybe it was the pre release viewer and went back to 1.19.1.(4) and still had the same problem:
Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release) CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2999 MHz) Well, to nobody's surprise, the "final" version of 1.20 is still leaking memory.
For completeness sake:
Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release) You are at 173093.4, 285612.8, 62.7 in Harrington located at sim3624.agni.lindenlab.com (216.82.22.105:13001) CPU: Intel Core 2 Series Processor (2399 MHz) Gonna be a tough one to shoot since there are still no dumps taken. The heap memory needs to be fenced so there's enough emergency memory to take a dump in. Second Life 1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)
CPU: Intel Core 2 Series Processor (2393 MHz) same out of memory bug here. same here. this has been going on for over a year. you'd think SOMEBODY woulda fixed it by now.
Second Life 1.20.14 (92115) Jul 14 2008 15:20:29 (Second Life Release Candidate) You are at 262245.7, 257962.4, 32.9 in Orientation Island Public located at sim5131.agni.lindenlab.com (8.2.32.132:13000) CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2666 MHz) I am getting this error on every single version of sl I run it has been going on for two months now non stop and I am getting really tired of it this didn't happen when I first got my vista can someone please help me or tell me what I can do to fix it!
Having done a little research, I find that SmartHeap (from MicroQuill Software Publishing) is supposed to enhance heap management under Windows.
I note that they have a special version "optimized" for symmetric multiprocessor environments...and all the folks having this problem are on SMP boxes. I wonder if: 1) There's an SMP bug in the version of SmartHeap shipped in SLV? 2) It's fixed in a later version of SmartHeap? 3) It's only fixed in the SMP version of SmartHeap? 4) If SmartHeap really makes SLV run better.? Inquiring minds want to know. CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2999 MHz)
Memory: 3327 MB OS Version: Microsoft Windows XP Service Pack 3 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 9800 GT/PCI/SSE2 OpenGL Version: 2.1.2 LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17508 (Mozilla GRE version I get this memory thing now. On my old computer with 512 of ram and nothing much of anything exciting i had 1.8 fps mostly after the new physics /windlight era(3 0r 5 before) but I could stay on sl indefinitely. I very rarely had sl close normally when i decided leave on the old comp, but since around the time the new physics I dint actually crash so often as i do now i have a new computer. I think what im doing is just normal stuff, but am always running an ao or other animation with two chat windows open- and i think moving into a high sculpty or 1024 text type environment while doing this does it, in the same region or after moving regions doesnt seem to matter. i dont run media/music. It seems to happen most when I have been on for a fair time and am witching between two im reply windows after changing from chat. It doesnt matter if i am running other apps or not . I use the /view movement and camera controls all the time. chosing ignore sometimes gives me a chance to tell one person or main chat im crashing, but once gave me five more minutes in a highsculpt 1024 texture environment in a slow script performance area- the only difference i could see to normal was not staying in ims. CPU: Intel Mobile Core 2 Duo T5500 mit 1,66GHz
Memory: DDR2 2048 MBytes OS Version: Windows Vista 32-Bit Home Premium Edition Service Pack 1 Graphic Card: Mobile Intel 965 Express Chipset Family Drivers are updated. I had the same problem the other people. Second Life crashed after 30 Minutes with the Smartheap and the Out of Memory Error. I then set the Pagefile of the Drive with Vista on it to 3072MB, Then uncheck the automatically manage my paginf file size After this i can play without any problems. Second Life did not crash even once after this change. CPU: Intel Mobile Core 2 Duo T8100 2.1 Ghz
Memory: 4.00 Gb RAM Graphics Card: nVidia GEForce 8600M GS, driver updated OS: Windows Vista 64-Bit Home Premium w/ latest service pack & updates I've loaded the latest SL release and had the "out-of-memory" problems which brought me here. I'm not sure really what Pagefiel or the 3072 is about, but because I have 4.0 Gb of RAM, should I be setting this to a higher number? Should this effect be any different with the latest 1.20 SL release? This is being closed as a duplicate. There are many different attempts at repros in the comments, but no one clear actionable item.
Please don't be discouraged from creating new JIRAs with sepcific, reproducible things you can do that make memory bloat. Otherwise, the general memory JIRA is enough to cover this one. Voters on this issue, please be aware that it's been closed as a dup of
I'm currently convinced this is a problem with thread-safety in an SMP environment, and most likely involves the texture caching code, so it's unlikely to ever yield an easy repro; it's going to take a code review, Already voted on the other issue. Don't know how easy the blasted repro has to be, I can reproduce it at will, it just takes time for the texture cache to fill up. Turn up draw distance to maximum, go someplace with lots of different textures, especially at the 4 corners of a sim so you can make use of all 4 of them, cam around (space navigator is good for this) for as long as it takes to get the memory usage up to 1.6 gb, wait for the error box. Do it with a console up and you'll see every time you click ignore you get a texture failed to load error. Not being able to repro shouldn't be an excuse for this one. i Beleave the Constant Crashes i am having Are in Relations to this Issue
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Showstopper
Memory leak: SmartHeap reports Out of Memory
Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)
You are at 255532.1, 243868.2, 22.1 in Aero located at sim4743.agni.lindenlab.com (63.210.159.139:13006)
Second Life Server 1.20.1.85162
CPU: AMD (Unknown model) (2812 MHz)
Memory: 4094 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.14690 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 5/67629 (0.0%)
Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a