| Key: |
VWR-2748
|
| Type: |
Bug
|
| Status: |
Reopened
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Ron Crimson
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
Custom-built PC, Asus P5LD2, Intel Core 2 Duo E6320, 3GB (3072MB) DDR2-667 memory, ATI Radeon X1600Pro PCI-E 512MB video card, onboard audio & network, Windows XP Pro SP2 up-to-date with all critical hotfixes, machine is dedicated to SL and runs almost nothing else in the background. Usually about 2.7GB-2.8GB free physical memory.
Custom-built PC, Asus P5LD2, Intel Core 2 Duo E6320, 3GB (3072MB) DDR2-667 memory, ATI Radeon X1600Pro PCI-E 512MB video card, onboard audio & network, Windows XP Pro SP2 up-to-date with all critical hotfixes, machine is dedicated to SL and runs almost nothing else in the background. Usually about 2.7GB-2.8GB free physical memory.
|
|
|
While it's well-known that the viewer tends to eat a ton of memory and eventually crashes, I observe a very particular behavoir for which I haven't found a pre-existing issue. My system has had 2GB of total RAM until recently and the viewer would always crash if that RAM was nearly completely full (less than 100MB remaining). After upgrading to 3GB, this continues to happen - but at the same point of reaching 2GB of used RAM, rather than continuing to use memory until all 3GB is full. It's as if Second Life doesn't know there's a third gigabyte of RAM there (whereas Windows, of course, does).
The crash itself happens very suddenly and without warning - no freeze or stuttering audio precedes it, the application simply quits back to the desktop in a split second and no further activity including disk swapping is observed. All the memory used by SL up to that point is immediately freed, Windows continues to run without problems and I can restart SL right away and continue with a new session.
My issue isn't with the fact that the viewer crashes, but that it apparently does so by being 'hard-coded' not to use any available memory beyond 2048MB (or that it attempts to do so but crashes trying to request RAM beyond the 2GB mark)....BTW, I use a nifty little systray app which displays current RAM usage as a mini-graph updated every 4 seconds (showing the last 60 seconds of usage) so I'm able to monitor it at all times while running the viewer in a maximized window - thus being able to reliably predict crashes about to happen due to hitting the 2GB barrier. Right before the viewer does crash, the systray monitor reports just a little over 1024MB as "free."
|
|
Description
|
While it's well-known that the viewer tends to eat a ton of memory and eventually crashes, I observe a very particular behavoir for which I haven't found a pre-existing issue. My system has had 2GB of total RAM until recently and the viewer would always crash if that RAM was nearly completely full (less than 100MB remaining). After upgrading to 3GB, this continues to happen - but at the same point of reaching 2GB of used RAM, rather than continuing to use memory until all 3GB is full. It's as if Second Life doesn't know there's a third gigabyte of RAM there (whereas Windows, of course, does).
The crash itself happens very suddenly and without warning - no freeze or stuttering audio precedes it, the application simply quits back to the desktop in a split second and no further activity including disk swapping is observed. All the memory used by SL up to that point is immediately freed, Windows continues to run without problems and I can restart SL right away and continue with a new session.
My issue isn't with the fact that the viewer crashes, but that it apparently does so by being 'hard-coded' not to use any available memory beyond 2048MB (or that it attempts to do so but crashes trying to request RAM beyond the 2GB mark)....BTW, I use a nifty little systray app which displays current RAM usage as a mini-graph updated every 4 seconds (showing the last 60 seconds of usage) so I'm able to monitor it at all times while running the viewer in a maximized window - thus being able to reliably predict crashes about to happen due to hitting the 2GB barrier. Right before the viewer does crash, the systray monitor reports just a little over 1024MB as "free."
|
Show » |
|
Viewer won't use physical RAM beyond 2 GB, crashes instead
Try http://searchwincomputing.techtarget.com/tip/0,289483,sid68_gci1108831,00.html to allow a single program to use all 3gb of the memory.
I'll leave the issue open for now though, because crashing once it reaches the 2gb limit would mean a memory leak, even though the limit itself isn't a bug.