I have noticed that many games (Farcry 2, Fallout 3, Fallout: New Vegas, Drakensang) crash with some form of out of memory messages. So obviously something is leaking memory (whether it is wine or the game or drivers, I cannot say). But it always happens as soon as wine uses ~1.5 GB of RAM. Also I wonder if it has something to do with this bug: http://bugs.winehq.org/show_bug.cgi?id=25428 I ran the Memory allocation test program attached to that bug and it only gets up to 1476 MB with wine, whereas it can allocate the full 2GB when compiled with gcc and run natively. I also linked it with -Wl,--section-start,.interp=0x7bf00400 as suggested by Alexandre, but that didn't make a difference. So my questions are as follows: - Can anyone (with a PAE kernel) confirm the bug report - Does anyone have a patch for current wine that implements the option of setting user space and kernel space memory limits. Or can anyone tell me where to find these limits in the source code. I'd like to play around a bit with these limits to force other distributions (eg. 3/1 GB split without LARGEADDRESSAWARE) to see whether this has an influence on this memory problem. My specs are: wine-1.3.25, AMD X2 2x3.0GHz, 4GB RAM (DDR2-800), GeForce GTX 285 (with NV proprietary driver 280.11), Creative SB X-FI.
Oh, forgot to mention: My kernel is version 3.0 built for k8 with 1 kHz timer and highmem (up to 64GB using PAE) support and fully preemtible.
possibly that high mem_PAE. patch you used. Its real best to use the x64 linux for higher mem rather then the PAE patch on x86. I am using x86 for the simple fact that some things in linux work better in x86 mode. also have 4gig of ram. now linux might only see 2.5 or 3 gig i forget. however even with windows7 and a high mem usage game like BF2, crysis, or battlefield bad company2, i would never fully use 3gigs of ram. so the reason i say to let that 1-1.5 free is to allow the memory to use it for cycles. memory is like buckets of water. only to keep the water fresh it need to keep sending the water to another bucket. Allowing and equal amount of buckets(ram free to ram used) free that the OS cant see still allows the Mother board to use it. so my conclusion is that if you use 1gig then 1 gig free allows that mother board free space for cycles. AND that the even if the OS cant see the ram the motherboard still does see the full amount of ram and uses all of it in cycling. If you are using up a lot of ram with the running processes then you really need to get x64 kernel OS. i have heard of many issues with the PAE. As for your issue having some thing to do with wine out side of what i covered this is still possible. If anyone can elaborate further on what i have said pls do.
On Sat, 2011-07-30 at 07:50 -0500, Kairhos wrote:> I have noticed that many games (Farcry 2, Fallout 3, Fallout: New > Vegas, Drakensang) crash with some form of out of memory messages. So > obviously something is leaking memory (whether it is wine or the game > or drivers, I cannot say). >Can you see anything useful by running 'top' in a console alongside the game that crashes? However, this will be no use if the game runs full screen because you won't be able to see the console window that contains it. If that's the case, what about using sar/sadf or pidstat? Both are part of the sysstat package. It is a standard Fedora package, so should be part of your distro too. If not, you can get it from http://freshmeat.net/projects/sysstat/ The most relevant parts of sysstat are 'sar', which silently snapshots and logs system stats which are analysed by 'sadf', and 'pidstat', which can display snapshots of memory usage by process. pidstat would be my starting point for seeing where the memory went, especially if the game runs full screen. For example: pidstat -r 2 10 >pidstat.log will make 10 snapshots of all active processes at 2 second intervals, capturing the output in pidstat.log. Martin> But it always happens as soon as wine uses ~1.5 GB of RAM. Also I > wonder if it has something to do with this bug: > http://bugs.winehq.org/show_bug.cgi?id=25428 > I ran the Memory allocation test program attached to that bug and it > only gets up to 1476 MB with wine, whereas it can allocate the full > 2GB when compiled with gcc and run natively. I also linked it with > -Wl,--section-start,.interp=0x7bf00400 as suggested by Alexandre, but > that didn't make a difference. So my questions are as follows: > > - Can anyone (with a PAE kernel) confirm the bug report > - Does anyone have a patch for current wine that implements the option > of setting user space and kernel space memory limits. Or can anyone > tell me where to find these limits in the source code. I'd like to > play around a bit with these limits to force other distributions (eg. > 3/1 GB split without LARGEADDRESSAWARE) to see whether this has an > influence on this memory problem. > > My specs are: wine-1.3.25, AMD X2 2x3.0GHz, 4GB RAM (DDR2-800), > GeForce GTX 285 (with NV proprietary driver 280.11), Creative SB X-FI. > > > >
@hotshotkev: I use an x86 kernel for the same reason. @Martin Gregorie: This is the output of top when Drakensang crashes and throws an out of memory error (I only included the first three processes as all other processes use less than 1% of memory at that time): Tasks: 110 total, 1 running, 108 sleeping, 0 stopped, 1 zombie Cpu(s): 0.7%us, 0.8%sy, 0.0%ni, 98.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4147096k total, 3537336k used, 609760k free, 31700k buffers Swap: 1959892k total, 0k used, 1959892k free, 1957400k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4632 melvin 20 0 2992m 1.3g 49m S 2 34.0 4:20.98 drakensang.exe 4635 melvin 20 0 6108 3200 684 S 1 0.1 0:05.56 wineserver 2848 root 20 0 72940 56m 14m S 1 1.4 2:13.54 Xorg
I did some more testing and you are absolutely right, Martin. It just reserves more and more virtual memory until the 3GB limit is reached, at which point it crashes. I fixed the problem by setting the LAA flag in the header of drakensang.exe. Unfortunately, you have to use a no-cd fixed exe because if you modify the original exe in this way, the copy protection of the game notices it and complains. I do not really understand why this works, as it was never a problem of not having enough real memory for the game. It still uses the same amount of memory with LAA set, but it doesn't grab all the virtual memory anymore. I tested it extensively by doing excessive zone changing. Without LAA it would crash after 6-10 zone changes. With LAA it still hadn't crashed after 64(!) zone changes (and the virtual memory of the process was still below 2.7GB), so I gave up testing and started playing normally. I've just finished playing for 5 consecutive hours (without a break) and it hasn't crashed once. Hence I can safely say that the problem has been fixed. Thank you both for your help/input. :)