[Bug 13335] libGL error when launching warcraft 3

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Mar 25 10:51:35 CDT 2009


http://bugs.winehq.org/show_bug.cgi?id=13335


Tony Wasserka <tony.wasserka at freenet.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|tony.wasserka at freenet.de    |




--- Comment #140 from François Gouget <fgouget at codeweavers.com>  2009-03-25 04:49:06 ---
Created an attachment (id=20117)
 --> (http://bugs.winehq.org/attachment.cgi?id=20117)
Test application

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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.


More information about the wine-bugs mailing list