Why Steam fails [VirtualAlloc]

Ivan Gyurdiev ivg2 at cornell.edu
Sun Dec 11 10:10:46 CST 2005


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?






More information about the wine-devel mailing list