|
|
|
[
Permlink
| « Hide
]
Gigs Taggart added a comment - 02/Apr/07 12:13 PM
This does not necessarily indicate a memory leak. As you download objects and textures, they are often cached in RAM.
@Dana: I noticed something similar when my computer really crawled and I noticed I hardly had any free RAM left. This was unusually high, not a problem I've had before with extended usage. I'm going to ask if this is the same thing as an existing memory leak issue we have, SL-34414.
I am seeing this as well. After 2-3 hours in world, my memory usage is approximately 1.5 GB.
System specs: Second Life 1.14.0 (1) Mar 30 2007 08:37:57
CPU: AMD (1837 Mhz) I noticed in Hair Fair 1 and 2 I also had this problem... only taking between 15-30 minutes, not hours. The oddity is that it did NOT appear to happen with cache set to 1GB - but DID happen with cache set to 500MB and 250MB (in the latter two cases, it would go to around 750MB and then BOMB crash out.) There are 5 or 6 automated crash reports in the queue now from me today alone, and probably others, as I overheard a lot of other residents complaining about their crashes and being "ruthed". The longer you use SecondLife, the more virtual memory use contiues to climb without bound. When quitting the viewer, watch the Performance tab of Windows' Task Manager and see how long it takes to release all the leaked virtual memory. It took several minutes on my slower system, watching the page file usage gradually go down from over a gigabyte. This kind of behavior almost always indicates a memory leak, where upon program termination, all the virtual memory pages need to be flushed from disk. This is also highly plausible given that SL Viewer is written in C++. To further diagnose this behavior, try running on a system that has had it's virtual memory reduced drastically.
I've added my description of what I believe to be this same issue. I noted that it is VIRTUAL memory that gets gobbled up, which happens after RAM is consumed, which happens very quickly.
I used to have this problem. My PC had only 1GB of ram, and I would crash often due to running out of memory.
My solution? I installed another 3GB. Bringing me up to a total of 4GB of RAM. Had no problems with this since. My ram usage barely ever goes above 2GB. That said, for those who aren't lucky enough to own a massive behemoth of a PC like mine, It would be nice to have this fixed. I have the misfortune of only having 256MB of RAM, a bare minimum for running SL. Prior to the last major version upgrade, I could use SL reasonably well if I avoided crowded areas. After the upgrade, even non-crowded areas, if they contained a number of textures, use up all my computer's memory and the hard drive starts running continuously as it attempts to keep going using the virtual RAM.
I assumed that this is the result of the new way textures are cached but perhaps it's a memory leak instead. In any case, while I'm sure 256MB isn't recommended, it would still be nice to have the same performance I had before that update. Keywords: memory leak
I'm experiencing similar problems to the above reports. I'll attach a screenshot showing how bloated Second Life got within the space of an hour, and what my page file looked like too. Thanks for the added info. My config:
Second Life 1.14.0 (110) Apr 10 2007 10:35:45 CPU: Dual (2301 Mhz) More places this bug has been mentioned:
http://forums.secondlife.com/showthread.php?t=178282 Several comments in (search for "memory leak"): http://blog.secondlife.com/2007/04/13/preview-of-second-life-11412-now-up-on-the-beta-test-grid/ Viewer memory leak is still present in this current mandatory release 1.15.0.2
I can second this bug. You can easily reproduce a crash it you go to catwalk city ... go walk through each floor, look at all shops, move up to the next level of that mall... CRASH... then you relog, have a look at the whole floor, massive trashing of textures on the harddisk, at the end of that floor... CRASH ...
Linux 1.15 viewer... 1GB ram, 768MB swap.
Usually not a noticable problem. But last night SL decided to eat ram. Was working fine for about an hour then suddenly shot up consuming all available ram / swap space. Had to move to console to kill SL. Usually hovers at all RAM + about half the swap. At the time I was standing in roughly the same spot in a music venue. The only thing I noticed changing was av's arriving for the gig, or it may have been linked to the parcel stream starting up. (Using OSS driver here). Any help? okay I'm not so smart when it comes to all this but would this be a huge contributing factor in why some of us cannot even stay in game long enough to play, now that they upgraded to the new mandatory version? We crash almost immediately if we do anything but stand in one spot and type. Also perhaps it is just related to the time we are in the game. Longest time these days now seems to be 5 min, maybe 10 just standing in one spot and using nothing but chat and IM. Any guidance out there? How do I check to see if its a RAM issue for me?
Interesting the note about the music venue; after experiencing lots of virtual and physical memory consumption by the current viewer, after quitting and waiting for all the swap pages to be flushed, I noticed the process Windows uses for audio (the 'container' process svchost.exe) was taking up much more than any other. This may or may not be a clue to the source of the leak being audio related.
I don't think it's related, Vee. Memory leaks are usually when the code allocates some memory then forgets to release it when it's done with it. If it does this enough times, things will start to fail because it's used too much memory. A 'leak' wouldn't cause you to get punted after only a few minutes.
This might explain the frequent crashes and program "hangs" in the mac OS X version, in which the client suddenly freezes and "hangs" cause you to get booted off the grid.
Hardware Overview: Machine Name: iMac One observation I have to share and which appears to not have been mentioned so far (although it may of course be incorrect or relative to my own system) is that the memory leak seems to be related to packet loss. I.e. I am observing that in times of high packet loss memory consumption is growing faster than at times when things run smoother. (Windows XP, CoreDuo, 1.5Gig memory, NVIDIA 7600). Also, what I observed was that on a different machine with a lo end graphics board (only 16MB Graphics memory and all advanced rendering options disabled) the program seems to be less prone to memory leaking. Additional comment: I only (mostly) see NVIDIA boards in the comments here. Confirmed.
Takes lots of memory, then more & more. Just sit in any place & wait... There can't be Hundreds of MBytes of textures coming from nowhere ! I get the same thing, and this has been happening since at least the last three clients. I upped my cache to 1G on a seperate drive from system, and it doesn't make any difference. Load the client and stay in SL for 10 minutes it will close quickly, stay in for an hour or so and it can take upwards of 4 minutes to completely close down.
CPU: Intel Pentium 4 (Unknown model) (3200 MHz) I'm assuming this is my problem.
It all started after 1.14. The viewer continually disk swaps virtual memory, even when I'm doing nothing. 500mb RAM 128mb video It seems to manifest in delayed response to motion keys. Maybe 3 to 5 seconds before depressing an arrow key and avitar motion. Al I have witnessed this problem now since the first release of the First Look client, in both Windows x64 and Windows Vista Ult 32-bit. I however am seeing it occur at a much faster rate than a "few hours" depending on my location. I have been able to steadily repro this bug by simply spending 5-15 mins. at a particular location I own in SL. Anywhere else, I can indeed sometimes stretch it out to that "few hours", however this one place is a guaranteed repro, and I have demonstrated it and provided everything I know to Steve Linden about it in the past.
Synopsis of the issue: Start client, goto known repro location and walk around for approx. 10 mins. Watch client in task mgr suddenly take a leap in memory from 300-500mb to 1.1GB + in a matter of seconds. In Wx64 it seems to handle the issue better, brings FPS down, but does not typically crash the client or system. In Vista, the client will cause bad FPS, typically a "TDR", full systems freezes, crashes, client will sometimes abnormally terminate with a C++ error and either crash to desktop or hard lock the entire system. This occurs and all seems consistent across the past 3 driver releases from Nvidia, both WHQL and BETA. CPU: Intel Core 2 Duo E6600 Major memory leak on the Intel mac side of things as well. Will post screenshots of activity monitor after running SL for a while,
(Macbook Pro 17" Core Duo (Yonah) 2.16GHz) This issue needs to be fixed badly.
I did notice where one of the leaks is located and its a very nasty one. I had 2 games running over night on a machine. One of the sims went down. The game that was now disconnected from that sim had its memory shoot up and keep growing at a huge rate. In under an hour it went from 100K to 600K and was growing. This caused the VM to increase like crazy, which caused the other game to crash. This crippled the machine, caused major Hard Drive thrashing. Rebooting the machine caused a CHKDSK, meaning some sort of corruption was CREATED by this leak. FIX IT!! OS: WinXP I am currently debugging this in the open source version. Anybody working on this as well, please contact me in-world for an exchange of observations, etc. I'm seeing a few things already, through the debugger and would like to exchange with others trying to fix this. I have spent a night debugging this and I have the suspicion that it's less of a memory leak but simply the application wasting memory in a big way. -------------- Observations (please verify anybody/everybody) (this is on a 1.5Gig machine, with high draw distance and pipelining):
--------------- Looking at the debugger, I can say the following:
---------------- Now, my current theory is the following: There may actually be no memory leak but something in the program design that makes 800MB to 1 GIG a "normal" memory footprint on wide and detailed sims (like malls, etc.). There may be some flaw in the design or ongoing flushing of the texture list, maybe some additional heap shredding ... but the bad news may be that it currently "works as designed".
Users who suspect a memory leak, after seeing high memory consumption please TP to a low prim sim (e.g. sandbox), stay there for a few minutes (two to five many) and check in the task manger if memory footprint decreases again. There's a "peak memory usage" in the taskmanager (View menu, Select Colums), check if Mem Usage drops to a value noticeably lower than peak. There are memory leaks in the viewer. We are doing what we can to minimize them however the gradual ones are difficult to track down. We are currently investigating tools to assist with this, however this is a time consuming process. If anyone has had success with any memory profilers with the Second Life code base, please send me an IM in world or email.
I have been digging further into this today, and I think there may be a mix of two issues here. Above I said that I saw the texture memory was eating huge chunks of memory, so I was looking into those routines. It appears that the texture system uses a function to determine the max amount of texture memory depending on the graphic card memory setting and the available memory. I also see that most contributors here are using graphics boards on the higher end (NVIDIA 7600/7800/8800) and the like. The way I currently understand it, texture memory is either roughly (1.25*graphics card memory) or (system memory - 128MB) ... whichever is lower. I had my system set to 512 MB graphics memory.which allows for about 680MB ram texture buffer plus the rest of the memory the program uses ... thus allowing a memory footprint of about 1GB. With a setting of 256 the footprint goes down to around 780MB and with 128 it's about 550 MB. So, depending on the adv. graphics settings (memory leaks nonwithstanding) a SL memory consumption of 1GB (assuming that there is enough physical RAM) can be considered normal (according to current design). Nicholaz, I'll try out setting my graphics mem down today. I do have it set at 512mb and my 8800 is a 640mb card. I'll turn it down to 256mb and start watching.
I do know about this "flush". When I leave the place I informed you of where I can replicate the issue, and goto my PI, when I can leave without a crash, yes the memory footprint will decrease on it's own sometimes. It seems very fickle though, I've had it come down from that 1.2gb ceiling to around 950mb-ish, sometimes as low as 750mb-ish. It seems the less time I spend in the mall, the more likely I'll somewhat recover that used memory, but not all. Rypth ... I am reasonably sure that that 1.2GB ceiling is intended behavior on your system and in that location. You have enough RAM so that does not limit the texture buffer, there are many textures there to fill it and with a 512MB setting on adv. graphics it will add a HUGE texture buffer in RAM on top of the program itself. On a system with just 1GB memory and a 512MB card, this will actually result in excess swapping because operating system plus SL will require about 1.4GB. See my new issue as https://jira.secondlife.com/browse/VWR-733 — There may be still issues with footprint slowly climbing, but if it's capped at about 1.1GB with 512MB vid RAM or around 750MB with 256MB vid RAM, it is intended behavior (as far as I can tell.) Having crashed out f0r the third time today. I have also noted very high RAM usage. this doubles everytime I teleport until the 4th teleport when it exceeds available 2Gb Ram. So far log in (560MB) and 1 teleport is giving me 1, 239,450KB memory usage Cache set to 500 MB
Intel duo core system with ATI graphics card. All specs are well in excess of minimal performance requirements, but is bespoke build. I'm attaching a leak dump from 1.15.0.2 via VS2003 (_CrtDumpMemoryLeaks) here. These are preliminary results, nothing solid yet. I spent a day now looking for leaks. What I can say is the following. Under the MS leak detection tools the program leaves, the longer it runs the more data behind. The problem is that I have no idea if that is intended (that is if the program simply does not clean up when closing and this is current stuff from the texture buffer) or if it's real leaks. But there are tons of leftovers from various places in the program ... the log attached to this issue indicates the most prominent ones (mainly the 160 bytes from viewerpartsource.cpp(line 205) ). I am having the suspicion that these are just legitimate parts which were not properly cleaned up, but if that is true, it is entirely pointless to look for leaks with this method. Besides that I found a handful of minor leaks there memory is left behind through error handling ... but these are, as far as I can tell minimal. I'm still looking into the leaks and just want to share some progress. I have a tool which lists stray memory at the end of the program and have identified one large source of leaking memory coming from web SSL/https requests. The source of the leak is one of the libraries Linden is using to handle https. I am not sure if the versions of the libraries on the source repository (I was downloading the precompiled lib packets from https://wiki.secondlife.com/wiki/Source_archive This is confirmed in their (curl's) change log and fixed as of March and using the latest version (which I was downloading and compiling to debug into the possible source) the leaks disappeared. Bottom line: if the current SL builds are using the same libs as on the linden opensource-archive, upgrading to curl-7.16.2 will fix a HUGE source of memory leaks. I am attaching patches for various issues, see descriptions inside the patches for details As a comment to my earlier posting. I am now running with task manager on standby and within 5 minutes, RAM is initially stable at 550MB, then gradually rises over time. After 1 hour it will normally be in excess of 750MB and after 2 may be as high as 1.5GB. that first hours rise was just standing doing nothing, on a very quiet sim.
The second life log file has been as high as 58Mb at times of crashing and contains the following error throughout in vast quantity: 2007-05-21T01:35:56Z WARNING: LLAudioChannelFMOD::update3DPosition error: An invalid parameter was passed to this function whether this is related to the high RAM usage....I am afraid I am no programmer. Other problem that may or may not be related is very low FPs even when no packet loss and 1Mb bandwidth usage An update to my issues with the memory leaks...
CPU: AMD (1837 Mhz) No matter what graphic card setting I have it set at, it does eventually crash - some settings do take longer than others, however. One thing I noticed yesterday, however, and I don't see this mentioned yet: Using the game's camera swing (alt+click) feature seems to accelerate the disk usage/thrashing/leakage symptoms for me. I spent about an hour teleporting around with little trouble - then used the camera swing to view stuff outside of about 100 meters. After that point, any future teleports resulted in my landing apparently in thin air, with stuff taking as long as 10 minutes to fully rez around me - including THE GROUND. Before then, stuff would rez decently. Even going to a low-prim, low-lag sim doesn't really fix this problem - things might pick up a little, but I'm still getting lots of thrashing and slow rezzing. The only fix for me is to relog and flush the cache. And boy, is that cache FULL when I do that - takes forever to flush it on a relog. Can't wait until this gets fixed... Intel Core2 Quad @ 2.66 GHz, 2.5GB RAM, 4GB paging file
2 - evga 8800GTS driving 4 1600x1200 flat panels Windows XP SP 2 Running the client in a 1600x1200 maximized (but not full-screen) window. Memory usage steadily increases, until it hits about 1.5GB, at which point the client (1.15 + 1.16 + FirstLook + current beta) crashes. This usually take 10-15 minutes and can be reproduced at will. If I minimize the client at any point, the "Mem usage" reported goes to about 150MB, but begins climbing as soon as the client window is restored. If I zoom in on something close and leave the view that way, the memory use increase very, very much more slowly. First, I want to thank Nicholaz for his valiant efforts. I tried reducing video memory. There was no effect. I do see a dramatic decrease in RAM usage, to less than 100 MB, when I minimize the sl window. There is no effect when I make the wondow smaller.
I generally load SL into about 20 meg of memory. I do see my memory useage go up slowly over several hours. This morning I noticed something I had not paid attention to previously. I was shopping so I was teleporting around every few minutes. After about 30-40 teleports my session became very slow and my HD light was solid. I checked my memory useage, I had hit around 712 meg. It seems the more I teleport the faster the memory leak. It seems thus to be directly tied to teleporting between sims. Now, for those of you wondering, I don't download or upload anything to SL. I just move around a lot. I stay in foreground mode and rarely go to background mode and I never minimize SL. I have 256 meg of memory on my video card. Since I only have 1 gig of memory when I hit 700+ meg of memory it's either shut down or crash time.
Dana et all! Basically, the fresh viewer without texture cache takes about 350MB (roughly speaking). There's nothing much to do about that. On top of that comes the texture cache, which in the current release build is depending on the adv.graphics-Video-size multiplied by roughly a factor or 1.3. The whole thing is capped by system memory, but there's a quirk in the current viewer build about that too. So basically, with a 128MB vid memory setting, the viewer will (once the texture buffer is filled up, like after being in a shop for a while) need at least 550MB of memory. Depending on time and network traffic (sim hopping requires more data fetched through the network), the viewer will genuinely leak about an additional 1-2MB per minute (the memory footprint mentioned above is more or less regular behavior). That means, on a 512MB XP System, the viewer will always swap (leak or not), but it will become more worse with every minute of network traffic (due to the leak). On the other hand, on a 1GB XP system it will run fine for a while until the leak will begin to fill up your memory and there is no end to that (it's just a question of online time). Without the leak, it would run find on 1GB for a long time (the other very minor leaks would take days to clog the memory usage). So, everything around 500-750MB usage is "normal". Minimizing the viewer will give a highly misleading number (generally the numbers from the task manager are not too accurate, because different things play in here). When minimizing the program, large parts of it will be shoved out to virtual memory on disk, which does not mean that the program needs less memory, it just means that it uses less real RAM at the moment, because XP pushed the rest out to disk. ------- So, bottom line: With a 512MB XP System, set your SL video settings to 128MB. On a 1GB system set them to 256MB to minimize (and minimizing is really the wrong word for a memory hungry application like SL) the regular as-designed memory usage and either live with the leak, relog every few hours) and was for the Lindens to fix the big leak. Alternately make your own build from the open source stuff or download and try my viewer build. Nick Ok I don't know whether this info will help. But the memory leakage I am experiencing is noticable slower on my home siim which is a class 4.
The sim where my business runs is a class 5 sim and giving me far more problems with memory leakage and slow FPS ( usuually about 1/2 what I can acheive on the home sim). Could there be a problem with the Class 5 sim coding that is agravating the position ?????. I understand your comments about large memory useage, however I never, I repeat NEVER start out in SL using more than 65 meg of active memory. I honestly don't pay any attention to virtual memory. Once my active memory reaches 200 meg or more I shut down and start over because the lag is unbearable. I run Windows XP Pro with a 3.2 GHZ hyper threaded CPS (without the hyper thread). It's not a new pc but adequate. There is a memory leak if (and I do) see it go up to 712 meg of memory if I just let it go. I understand what you're saying, I've programmed but mainly in COBOL, not much Java. COBOL doesn't memory leak. Internet applications do. So much for a better system.
Between the memory leaks, constand crash's, can't log on, and all the bugs that make SL just not fun to fight with I still use and enjoy my time in SL. I wish customer service and fixing operational and programming issues were the primary interests of SL rather than growing the business. If these issues aren't fixed the big businesses will get fed up and leave. It's just a matter of time. Customer service keeps a business running. I know I'll pay twice the price for good customer service and never look back. Poor customer service is just a good reason to quit. Money is never the issue. I hope you fix the memory leak. It causes more grief than anything else in SL, at least for me. Everything else is just an annoyance. Well, just that nobody gets confused (because I'm posting so much about this): I'm not a Linden  Most of us know you are not Nicholaz, As I am not a programmer either. But we very much appreciate your efforts to try and isolate what is in fact causing these huge memory leakage problems.
The update to libcurl 7.16.2 will be present in 1.17.0, and addresses the biggest leak. It should be hitting the public beta / source code drop today.
Please continue to file newly identified viewer memory leaks in new bugs for easier tracking. Added a note at the top to clarify what the meaning of this bug being marked "resolved" is, and added a word to the title accordingly.
Memory Leak not resolved, client chewing up commit charge memory faster now then before, unable to get it to go down without relogging client.
If more then 1 Client running (ie. 2 clients) when shutting down first reduced commit charge a bit but once the second client comes back online the commit charge memory is using even more then before the 2nd client was logged. In under 3 hours have already eaten up 700Meg of Commit Memory Start: 1100 MB used and climbing........ Marking this as resolved internally, the libcurl changes missed the initial 1.17 release and will make it in as either an optional update or the next mandatory update. This is due to that we have libcurl running on the sims as well and may need to keep them both in sync to be compatible.
NOT yet fixed, according to Milo - should stay at "fixed internally" until there's been another release.
Re-marking as "Fixed Internally" – resolved in "update-libcurl-7.16.2 r63010" branch and verified by Milo.
I'd hate to rain on the parade of any who believe that all leaking of memory by the SL client has been fully plugged; there still seems to be a GDI resource leak, but not necessarily a fault with the CODE, but rather with MS VC++ itself. I have reported the same behavior: constant PF usage growth over time from running MS VC++ program in Windows XP, and it's an artifact of VC++ interacting with Windows, not the C code.
Means to reproduce the problem: run SL client for hours and hours, observe PF usage go up and up, quit the program, watch it go back down again. Only with this other system written in VC++, quitting does not cause the PF use to restore to original, but rather it REMAINS HIGH. Logging out user from Windows does not restore it. Only rebooting Windows fixes the PF usage. So although the SL client memory leaks may appear to all be plugged, the very fact it's compiled by Visual Studio 2003 and not 2005 is causing it to still leak resources. The recommendation I got from Microsoft is to use 2005, not 2003 as your development platform. I will report back here the results of the experiment on this other software system to verify the fact that GDI resource leaks are a knowin issue with MS VC++ 2005. Eric - note that this bug isn't actually fixed yet, as they want to roll out the new libcurl on both the sims and the viewers at once... It might be possible that you're still seeing this same libcurl leak.
Also, you should put non-libcurl stuff in a new issue. See Milo Linden's comment above. )) So although the SL client memory leaks may appear to all be plugged, the very fact it's compiled by Visual Studio 2003 and not 2005 is causing it to still leak resources. The recommendation I got from Microsoft is to use 2005, not 2003 as your development platform. I will report back here the results of the experiment on this other software system to verify the fact that GDI resource leaks are a knowin issue with MS VC++ 2005. (( I'd really like to see refernces to this, because I can not observe this behavior. Even if it exists in regard to GDI, the Linden viewer does not make extensive use of GDI (hardly any at all), so even if they'd loose all their GDI objects (which they don't ... handle count in the taks manager patforms at a count around 500), I doubt that they'd be able to make the page file grow with this. Fixed in 1.17.1. More info @ http://blog.secondlife.com/2007/06/26/optional-viewer-and-rolling-restart-this-monday-june-25th/
 This issue isn't fixed yet!!!
I can find it both on WinXP and UbuntuLinux... And on different PCs... I also tried last release candidate versions, but nothing.... And I think that I'll have to leave SL if this problem won't be resolved: I can't stay online more than 10 minutes! Then the RAM finish, virtual memory grows exponentially, and all the PC crash, with the hard disk working for hours... That's no possible! Please, what can I do?!? Thanks to everyone who are working on this... Bye Simeone - you will have to re-open this (with back-up) in order to get attention for it.
Sorry to interfere here, but this particular leak caused by libcur is definitely fixed and not back since 1.16, so I'm removing the later versions from this issue. If you want to add info to newer versions or new leaks (yes, there are new ones), VWR-2477 may be the right place. I am having the memory build up problem running Win XP service pack 1, mem 512mb, in both Monzilla Firefox and Windows Internet Explorer. The page file builds and builds as I move around, or stand sit still untill I can't move at all.
What is the solution to this problem? Without a fix, I can't use SL. System requirements are 512 of ram, but the way it works, you really need 2+gig! This sucks!! There are still very serious memory leak issues with all Second Life clients. For me, a user with 1 Gig of memory, having Mozilla open with many tabs (multiple web sessions inside a single window), and/or being on Second Life in a sim with a certain number of people nearby, and high of objects and attachments present, will cause SL to crash for me... either the client screen simple disappears and I get the crash-report sending request dialog, or the SL client window goes completely white, and I have to kill the second life client process and start it over again. PLEASE SEE VWR-2997
Am wondering if memory leakage has worsened under 1.19.1 RC0 – Page file is now nearing 2 GB on my (older) system. It's almost always been large, but leaks were addressed with some success when this issue originally surfaced back in Spring/Summer 2007. It seems like probable new leaks are emerging as the present 1.19.1 (0) Release Candidate seems to become increasingly unstable and slow with time online. Then again, it could be my boat anchor of a machine, running Win XP SP2 with a mere 1GB of RAM. Still, the new RC seems pretty fast and stable when first loaded, and that page file does seem to keep creeping up in size over time. I've been mainly messing with the new media calls via LSL, so it's also possible (I'd guess) that the root of the problem lies in this first hack at expanding the uses of Parcel Media streams to handle Webpage display on a prim. Perhaps the leak is in how I am calling pages, loading them, and refreshing the same page repeatedly by way of calls to the parcel media functions in LSL?
Also, the crash logger has gotten a habit lately of getting into an infinite loop when it says that it's transmitting logs, and eventually has to be terminated manually in most instances. Crashes, though, are not a universal experience with this RC. At least not for my installation. Tentative reopening. Possible this is not an issue for others, but it seems very similar in character to behavior last noted when this issue was active. See comments entered in the general comment section for further detail, such as it is.
The patches provided above are windows only.
there are no patches for mac OS X. I have found this problem after not noticiing it before, since I installed the latest version of the viewer. It also seems to correlate with Mozilla Firefox running, but generally happens with little else int he back ground. RAM usage goes from 250MB to 750MB in 30 minutes, and seems to steady out at 1.2GB after 90 minutes when my system starts to struggle. Re-starting the viewer completely resolves the issue.
Ditto what Azadine says about the crash logger looping too. Second Life 1.19.0 (5) Feb 28 2008 17:18:12 (Second Life Release) You are at 189567.8, 259871.4, 35.3 in Hathian located at sim5625.agni.lindenlab.com (8.2.34.181:12035) CPU: AMD (Unknown model) (2010 MHz) Suggest closing this issue in favor of VWR-2477, as 2477 seems to be far more appropriate to what I and others seem to be seeing lately, especially under 1.19.1 RC1. The Crash logger issue mentioned here by me and by Misti Rustka probably needs its own issue, and seems to have improved but not disappeared under 1.19.1 (1)?
This issue should really be closed. It had a specific cause (libcurl) which was fixed a long time ago. Yes, there are new leaks, but this one is definitely fixed (and I know what I'm talking about because I was the one who found it). Closed per Nicholaz's comment.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
Viewer memory leak (over several hours) (libcurl)
