Here is why I think Steam fails on my machine: The issue: Half of the time Steam fails to start, with this helpful message, and no wine output: memstd.cpp (148) : Assertion Failed: 0 Then it goes into the minidump and writes a 3G file on my disk or so that I need to erase.. =========== It seems like it tries to reserve 200 MB of memory via VirtualAlloc, and then subsequently commit a small portion of that (again through VirtualAlloc). Then it fails some sort of assertion. It doesn't seem to check the retval of the first alloc, which fails about half of the time in wine_anon_mmap (mmap() call) with ENOMEM. If the allocation succeeds, Steam proceeds to run. If it fails, Steam dies with the message above. This is a machine with 1G memory. How much memory does one need to run Steam? Isn't this supposed to be a Virtual allocation...Why does it work one time, and not the other... The manpage for mmap() says ENOMEM can occur if the process exceeds its allowed number of mappings. Is this relevant?
Hello,
It doesn't seem to check the retval of the first alloc, which fails about half of the time in wine_anon_mmap (mmap() call) with ENOMEM. If the allocation succeeds, Steam proceeds to run. If it fails, Steam dies with the message above. I just started Steam 5 times without a single failure. I can't reproduce the problem.
This is a machine with 1G memory. How much memory does one need to run Steam? I have 512 MB, but I think 128 should be enought for Steam alone.
Isn't this supposed to be a Virtual allocation...Why does it work one time, and not the other... The manpage for mmap() says ENOMEM can occur if the process exceeds its allowed number of mappings. Is this relevant? Maybe you should check your /etc/limits file. Your distro might have limited the amount of memory a user may allocate. If you don't mind security risks, you could try to run Steam as root, and see if the problem continues. But back up your MBR first ;)
Stefan
Stefan Dösinger wrote:
Hello,
It doesn't seem to check the retval of the first alloc, which fails about half of the time in wine_anon_mmap (mmap() call) with ENOMEM. If the allocation succeeds, Steam proceeds to run. If it fails, Steam dies with the message above.
I just started Steam 5 times without a single failure. I can't reproduce the problem.
I think I'm the only one with that problem... and I can't figure out what's wrong :(
Isn't this supposed to be a Virtual allocation...Why does it work one time, and not the other... The manpage for mmap() says ENOMEM can occur if the process exceeds its allowed number of mappings. Is this relevant?
Maybe you should check your /etc/limits file. Your distro might have limited the amount of memory a user may allocate.
The limits are the default ones - all lines in that file are commented out.
If you don't mind security risks, you could try to run Steam as root, and see if the problem continues. But back up your MBR first ;
I tries that with the exact same results... Attempted mmap_anon of size 200MB...fails...Steam fails, with ENOMEM.
I tries that with the exact same results... Attempted mmap_anon of size 200MB...fails...Steam fails, with ENOMEM.
Here's the exact mmap call... it's the only one that fails, and it's the largest without MAP_NORESERVE. mmap2(NULL, 209780736, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) Running the same call from a test program suceeds - I can mmap() things that are an order of magnitude larger without problems (as a regular user).
On Sat, 03 Dec 2005 15:38:10 -0500, Ivan Gyurdiev wrote:
Running the same call from a test program suceeds - I can mmap() things that are an order of magnitude larger without problems (as a regular user).
How big is your swapfile? It should probably have a MAP_NORESERVE flag.
Mike Hearn wrote:
On Sat, 03 Dec 2005 15:38:10 -0500, Ivan Gyurdiev wrote:
Running the same call from a test program suceeds - I can mmap() things that are an order of magnitude larger without problems (as a regular user).
How big is your swapfile? It should probably have a MAP_NORESERVE flag.
Which swapfile.. I'm not very familiar with how memory management works... I have a swap partition of size 512 MB (or so), and 1GB of actual memory. The NORESERVE flag was not set in the mmap call that's breaking Steam... and it wasn't set in my test program either. Here's output from free command right now... it looks about the same that it did when Steam wouldn't run... total used free shared buffers cached Mem: 1035604 947792 87812 0 84480 498200 -/+ buffers/cache: 365112 670492 Swap: 524152 188 523964
Ivan Gyurdiev wrote:
I tries that with the exact same results... Attempted mmap_anon of size 200MB...fails...Steam fails, with ENOMEM.
Here's the exact mmap call... it's the only one that fails, and it's the largest without MAP_NORESERVE.
mmap2(NULL, 209780736, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
You've probably got a fragmented address space caused by having a lot of dynamic libraries loaded at different addresses...
Running the same call from a test program suceeds - I can mmap() things that are an order of magnitude larger without problems (as a regular user).
...which doesn't happen in your test program as it doesn't use as many. Remember that it takes only one page of memory sitting at the wrong virtual memory address to divide the available contiguous addresses in half. I would suggest playing around with the prelink tool to put dynamic libraries in better positions in memory. Rob
...which doesn't happen in your test program as it doesn't use as many. Remember that it takes only one page of memory sitting at the wrong virtual memory address to divide the available contiguous addresses in half. I would suggest playing around with the prelink tool to put dynamic libraries in better positions in memory.
I can take a look, but this is a Fedora Rawhide machine, which should run prelink nightly.
On Mon, Dec 05, 2005 at 03:11:33AM -0500, Ivan Gyurdiev wrote:
...which doesn't happen in your test program as it doesn't use as many. Remember that it takes only one page of memory sitting at the wrong virtual memory address to divide the available contiguous addresses in half. I would suggest playing around with the prelink tool to put dynamic libraries in better positions in memory.
I can take a look, but this is a Fedora Rawhide machine, which should run prelink nightly.
I found our mmap - reserve area handling to be problematic for low memory machines... You can try disabling it (just check libs/wine/mmap.c, mmap_init() and change the first #if to #if 0.) Ciao, Marcus
...which doesn't happen in your test program as it doesn't use as many. Remember that it takes only one page of memory sitting at the wrong virtual memory address to divide the available contiguous addresses in half. I would suggest playing around with the prelink tool to put dynamic libraries in better positions in memory.
I can take a look, but this is a Fedora Rawhide machine, which should run prelink nightly.
I found our mmap - reserve area handling to be problematic for low memory machines...
You can try disabling it (just check libs/wine/mmap.c, mmap_init() and change the first #if to #if 0.)
Thanks for the suggestion, but it doesn't help. I don't think this is a low-memory machine - it has plenty of memory (1G + 512 swap), and most if it is unused. The gnome resource monitor shows 30-40% usage, and it doesn't spike at all when steam is used. I see some libraries didn't prelink in the log, so I'll try Rob's suggestion, and see if prelink helps things. I am not optimistic though - I've seen this problem for a long time...
On Sat, 03 Dec 2005 20:39:01 -0600, Rob Shearman wrote:
I would suggest playing around with the prelink tool to put dynamic libraries in better positions in memory.
Another thing to try is disabling execshield and VMA randomization: echo 0 >/proc/sys/kernel/exec-shield echo 0 >/proc/sys/kernel/randomize_va_space thanks -mike
Mike Hearn wrote:
On Sat, 03 Dec 2005 20:39:01 -0600, Rob Shearman wrote:
I would suggest playing around with the prelink tool to put dynamic libraries in better positions in memory.
Another thing to try is disabling execshield and VMA randomization:
echo 0 >/proc/sys/kernel/exec-shield echo 0 >/proc/sys/kernel/randomize_va_space
That doesn't help - neither does overcommit as another poster suggested. It turns out that prelink was, in fact, broken, and not working at all. The cause was circular dependencies caused by libsafe (see Fedora Extras) which propagated down to the rest of the system (I have no idea how, but libsafe makes everything link to it somehow). Filed a bug. So, after getting rid of libsafe, prelinking, and rebooting, my memory consumption is down by 200MB or so... down from 40% to 20%. Not bad... And yet... Steam *still* manages to fail with 800 MB memory free somehow... Something's not right about that. Again it fails sometimes, not persistently. More info: 1. I used to kill Steam when it crashed, since it tried to write a 3G log file on disk... however, I hadn't noticed it had stopped doing that with recent upgrades (of steam). Now it quits after a while, and reports Windows Structured Exception: Could not write to virtual address 4 without appropriate access rights. (but the ENOMEM is still there, and I'm pretty sure that's making it fail). 2. I don't know if this is the expected result, but here's prelinking libwine: /usr/sbin/prelink: /usr/local/lib/libwine.so.1: Unknown stabs code 0x2e ...and all its dependencies under lib/wine fail. 3. Fedora default prelink flags are: # Options to pass to prelink # -m Try to conserve virtual memory by allowing overlapping # assigned virtual memory slots for libraries which # never appear together in one binary # -R Randomize virtual memory slot assignments for libraries. # This makes it slightly harder for various buffer overflow # attacks, since library addresses will be different on each # host using -R. PRELINK_OPTS=-mR I haven't changed those... should I?
Ivan Gyurdiev wrote:
3. Fedora default prelink flags are:
# Options to pass to prelink # -m Try to conserve virtual memory by allowing overlapping # assigned virtual memory slots for libraries which # never appear together in one binary # -R Randomize virtual memory slot assignments for libraries. # This makes it slightly harder for various buffer overflow # attacks, since library addresses will be different on each # host using -R. PRELINK_OPTS=-mR
I haven't changed those... should I?
Remove the R option from above. That will cause you to have a VM layout with less gaps and more contiguous memory. If this still doesn't work, you will have to look at /proc/<pid>/maps to see why the address space is so fragmented. Rob
On Sat, 2005-12-03 at 15:02 -0500, Ivan Gyurdiev wrote:
Stefan Dösinger wrote:
Hello,
It doesn't seem to check the retval of the first alloc, which fails about half of the time in wine_anon_mmap (mmap() call) with ENOMEM. If the allocation succeeds, Steam proceeds to run. If it fails, Steam dies with the message above.
I just started Steam 5 times without a single failure. I can't reproduce the problem.
I think I'm the only one with that problem... and I can't figure out what's wrong :(
Isn't this supposed to be a Virtual allocation...Why does it work one time, and not the other... The manpage for mmap() says ENOMEM can occur if the process exceeds its allowed number of mappings. Is this relevant?
Maybe you should check your /etc/limits file. Your distro might have limited the amount of memory a user may allocate.
The limits are the default ones - all lines in that file are commented out.
If you don't mind security risks, you could try to run Steam as root, and see if the problem continues. But back up your MBR first ;
I tries that with the exact same results... Attempted mmap_anon of size 200MB...fails...Steam fails, with ENOMEM. Wow, thats really weird...I can also use steam without incident (I can even play Half-Life 2, the only issues I get are some intermittent sound lags.) Perhaps there's something wrong with your RAM? Have you tested any other apps that use about as much as Steam uses (about 200 MB max in my experience) on either WINE or native apps?
James
Wow, thats really weird...I can also use steam without incident (I can even play Half-Life 2,
... Half-Life 2 doesn't even run for me if I get Steam to start up.. it goes to fullscreen, and freezes the screen (without covering anything up). I am suspicious of hidden dialog boxes (like in GTA), but I haven't tried to investigate that problem in detail yet.
the only issues I get are some intermittent sound lags.) Perhaps there's something wrong with your RAM? Have you tested any other apps that use about as much as Steam uses (about 200 MB max in my experience) on either WINE or native apps?
Xorg? Warcraft 3? Gnome? KDE ? Doom 3? I've had Half-Life 2 working back with Oliver's very first patch.. or with Cedega.. I think hardware problems with the RAM are highly unlikely. I've had plenty of those, and when your RAM is defective, nothing works - you get spurious kernel panics, and you will find out that it's defective really soon.
On Mon, 2005-12-05 at 03:24 -0500, Ivan Gyurdiev wrote:
I think hardware problems with the RAM are highly unlikely. I've had plenty of those, and when your RAM is defective, nothing works - you get spurious kernel panics, and you will find out that it's defective really soon. Well, that might be true most of the time, but not always. Case in point: a while back I was helping a friend of my brother's build a computer. We loaded Windows XP and a couple games on it (Half-Life, Max Payne, a few others which I can't remember) Things seemed to work fine. Then we tested the games. Everything except HL hard-locked the machine. It drove us nuts all night trying to figure it out. The next day the guy swapped out his ram (for reasons I can't explain) and things worked fine. It just goes to show that sometimes it can be what you least expect... ;-) I wish I could shed a little more light on your plight though. I wish you the best of luck :)
James
On Mon, 2005-12-05 at 00:41 -0800, James Liggett wrote:
On Mon, 2005-12-05 at 03:24 -0500, Ivan Gyurdiev wrote:
I think hardware problems with the RAM are highly unlikely. I've had plenty of those, and when your RAM is defective, nothing works - you get spurious kernel panics, and you will find out that it's defective really soon. Well, that might be true most of the time, but not always. Case in point: a while back I was helping a friend of my brother's build a computer. We loaded Windows XP and a couple games on it (Half-Life, Max Payne, a few others which I can't remember) Things seemed to work fine. Then we tested the games. Everything except HL hard-locked the machine. It drove us nuts all night trying to figure it out. The next day the guy swapped out his ram (for reasons I can't explain) and things worked fine. It just goes to show that sometimes it can be what you least expect... ;-) I wish I could shed a little more light on your plight though. I wish you the best of luck :)
James
Just run memtest86 on the machine overnight. That'll tell you whether there's a hardware memory issue or not. -Scott Ritchie
On Saturday 03 December 2005 15:02, Ivan Gyurdiev wrote:
Stefan Dösinger wrote:
Hello,
It doesn't seem to check the retval of the first alloc, which fails about half of the time in wine_anon_mmap (mmap() call) with ENOMEM. If the allocation succeeds, Steam proceeds to run. If it fails, Steam dies with the message above.
I just started Steam 5 times without a single failure. I can't reproduce the problem.
I think I'm the only one with that problem... and I can't figure out what's wrong :(
How's your swapfile size? Maybe your system doesn't do overcommits, thus there must be enough physical ram + swapfile for all virtual allocations. That'd be the only thing that I could think of, although whether overcommits can be disabled and so on I don't know. So I might be just rambling insanely ;-) Cheers, Kuba
Hi, On Mon, Dec 05, 2005 at 09:07:45AM -0500, Kuba Ober wrote:
On Saturday 03 December 2005 15:02, Ivan Gyurdiev wrote:
I think I'm the only one with that problem... and I can't figure out what's wrong :(
How's your swapfile size? Maybe your system doesn't do overcommits, thus there must be enough physical ram + swapfile for all virtual allocations. That'd be the only thing that I could think of, although whether overcommits can be disabled and so on I don't know. So I might be just rambling insanely ;-)
overcommitting is default and I knew that there was a way top turn it off, so a find /proc -name "*commit*" found: /proc/sys/vm/overcommit_ratio /proc/sys/vm/overcommit_memory Oh wait, it seems it's not default: $ cat /proc/sys/vm/overcommit_memory 0 Andreas Mohr
I think I'm the only one with that problem... and I can't figure out what's wrong :(
How's your swapfile size? Maybe your system doesn't do overcommits, thus there must be enough physical ram + swapfile for all virtual allocations. That'd be the only thing that I could think of, although whether overcommits can be disabled and so on I don't know. So I might be just rambling insanely ;-)
overcommitting is default and I knew that there was a way top turn it off, so a find /proc -name "*commit*" found:
/proc/sys/vm/overcommit_ratio /proc/sys/vm/overcommit_memory
Oh wait, it seems it's not default:
$ cat /proc/sys/vm/overcommit_memory 0
Nevertheless I acknowledge that a compounding issue is VM fragmentation of a process. Redoing the prelink & friends would be one way to attack that. Another issue is how safe it really is to allow overcommits. They are off on my FC4 system too. Cheers, Kuba
participants (9)
-
Andreas Mohr -
Ivan Gyurdiev -
James Liggett -
Kuba Ober -
Marcus Meissner -
Mike Hearn -
Rob Shearman -
Scott Ritchie -
Stefan Dösinger