Francois Gouget a écrit : [...]
Unfortunately I couldn't reproduce this problem as I only have a FreeBSD virtual machine.
I attached a test application to bug 13335 to reproduce this issue without needing OpenGL support. Here's the corresponding comment: http://bugs.winehq.org/show_bug.cgi?id=13335#c140
It does confirm that FreeBSD only uses memory above the main exe. So the higher that application is loaded, the less memory can be used.
It seems pretty broken of FreeBSD to behave like that though. Is there a chance that it could be fixed there?
I'm reproducing the comment I entered in Bugzilla here for reference:
I am attaching a nice little application which can be used to reproduce and analyze this issue, without requiring an OpenGL capable machine (so it can be used in virtual machines).
What it does is allocate memory via either Unix malloc() or Unix mmap(). The nice thing is that you can compile it as a Winelib application, but also as a native application, including as a native application loaded at a specific address (all the instructions are in the C file). So you can use it to compare the situation in Wine with the one in native applications. For instance to allocate 500 chunks of 10MB, call it as follows:
./memtest malloc 10 500 or ./memtest mmap 10 500 or wine ./memtest.exe.so malloc 10 500 or wine ./memtest.exe.so mmap 10 500
Of course you won't be able to allocate 5GB of memory, the allocations will start failing before that (don't worry it won't bring down your machine, we have overcommit to thank for that). But what's interesting is that you'll get the addresses of all the successful allocations, the total amount of memory allocated, and a pause at the end of the application so you can inspect the memory map (via winedbg or /proc).
Here are some results: * Native on Linux Allocations start around 0xb74e8000 and go down to x00300000, then to 0xb805f000 and up to 0xbee5f000 for a total of around 3000MB allocated. The application load address has no impact.
* Winelib on Linux Allocations start at 0x7e053000 and go down to 0x60700000 so that only 480MB can be allocated. Everything below that is reserved.
* Native on FreeBSD 7.0 Allocations start after the main executable and go up. So by default they start around 0x28300000 and go up to 0xbed00000 for a total of around 2400MB allocated. But if the executable is loaded at a higher address, such as Wine's default 0x7bf00400, then allocations start at 0x9c200000 and end at 0xbe800000 so that only 560MB can be allocated.
* Winelib on FreeBSD 7.0 Allocations start at 0x7e4dd000 and end at 0x7eedd000 so that only 20MB can be allocated. That's obviously way too little.
It would be nice to retry this with the mmap patch, but unfortunately it does not apply anymore.