[Bug 21962] Call of Duty 4 crashes

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Apr 9 13:22:31 CDT 2010


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





--- Comment #52 from Stefan Dösinger <stefandoesinger at gmx.at>  2010-04-09 13:22:29 ---
Created an attachment (id=27301)
 --> (http://bugs.winehq.org/attachment.cgi?id=27301)
Check for mapped buffers in preload

It seems that the game draws while the buffer that it uses for drawing is
mapped. This isn't legal in GL, and I am pretty sure shouldn't be legal in d3d.
The game may get away with it by luck however.

Can you try this patch? If checks if the buffer is mapped when PreLoad is
called, and if it is, prints an error message and causes the app to exit(so
other FIXMEs don't spam too much). It should confirm or deny my theory.

I think this is what happens:

1) The app creates a buffer
2) It maps the buffer
3) It draws with the buffer
In this step the original map address is already freed and invalidated, but
this doesn't have to cause a crash. We're (correctly) setting up GL to draw
from the buffer.
4) It unmaps the buffer
This step generates a GL error. However, the checkGLcall call for the unmap
buffer call is missing, so you don't see it yet. (We should add a checkGLcall
line there)
5) It locks the buffer again
At this point, the GL buffer is mapped. A checkGLcall line is executed and
retrieves the error generated in step 4, which wasn't seen yet by (bad) luck.
This explains why glMapBufferRange seems to generate an error but still returns
a valid address.
6) The app draws from the buffer. This generates another GL error because the
buffer is mapped
7) Unmap
8) 5-7 repeat a few times.
9) At some point PreLoad (incorrectly) drops the GL buffer because it thinks it
will work more efficiently without it. No new heapMemory is allocated because
resource.allocatedMemory is already set. The mapped GL memory is lost.
10) At some point the kernel cleans up the memory and the app crashes.

Now, with the patch that fixes the incorrect VBO drops, the VBO is not
released, and the memory never becomes invalid. However, the app keeps drawing
while the buffer is mapped, which is correctly rejected by GL.

I do not see the draw-with-mapped-buffer behavior myself. I have two theories:
*) Do you have a cracked game? Maybe the crack is bad.
*) There's an unexpected exception somewhere between the Map and the draw, and
the app catches this exception. So it doesn't crash outright, but doesn't
properly work either.

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