[Bug 13335] libGL error when launching warcraft 3

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Apr 3 13:46:36 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    |

Gerald Pfeifer <gerald at pfeifer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gerald at pfeifer.com

Brian Rogers <brian at xyzw.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brian at xyzw.org




--- 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.


--- Comment #141 from Rico <kgbricola at web.de>  2009-03-27 06:46:08 ---
Created an attachment (id=20139)
 --> (http://bugs.winehq.org/attachment.cgi?id=20139)
Results of the test application for different plattforms (linux{32,32pae,64})

Attached is the result for the test application for different linux versions
(32Bit, 32Bit+pae, 64Bit, +wine).

The result is that wine shows on all tested linux platforms the same behaviour.
This proves my comment (http://bugs.winehq.org/show_bug.cgi?id=16456#c48) and
shows that this hasn't any influence on the tested platforms which wine is used
on.


--- Comment #142 from Rico <kgbricola at web.de>  2009-04-02 14:31:39 ---
>It would be nice to retry this with the mmap patch, but unfortunately
>it does not apply anymore.

Your test app doesn't trigger any call to mmap (with modified mmap patch). So
the result is identical to my previous test. Could anyone confirm that?


--- Comment #143 from Rico <kgbricola at web.de>  2009-04-03 13:44:51 ---
Created an attachment (id=20275)
 --> (http://bugs.winehq.org/attachment.cgi?id=20275)
Test results with wglgears on wine on different linux versions (32Bit,
32Bit+pae, 64Bit, 64Bit+mem4g)

This test addresses the speed problem on several machines.

Attached is the test run of wglgears on wine on different linux kernels with a
nvidia graphics card. The result is that in every frame on a clean 64Bit system
there are 3 additional mmap/munmap calls which aren't there in any other run
(32bit,32bitpae,64bitmem4g).

Is there an ati user with a machine like this (x86_64, ati card, 4+GB ram) who
could run the test?




-- 
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