[Bug 18799] Crysis: Silent crash after first intro scene

[wine-bugs at winehq.org]

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

--- Comment #37 from Stefan Dösinger <stefandoesinger at gmx.at> 2011-02-04 10:43:24 CST ---
I investigated the crash a bit, and it seems that the game indeed tries to
access the buffer contents without locking the buffer. This is roughly
equivalent to accessing memory after HeapFree()ing it. Essentially the game
creates the buffer, locks it, writes data into it, unlocks it, draws a few
times. This happens while the loading screen is visible. Then the game calls
d3ddevice::reset(), draws the scene where the alien ship opens. Then it
crashes, apparently trying to access the contents of a number of vertex
buffers.

With the patch from Rico the Wine copy of the vertex buffer is still at the
same place. Without it, the old pointer is long gone, because the first lock
goes into the sysmem copy, which is deleted after the VBO is created to save
memory. Rico's patch keeps this copy around, so the access to the buffer memory
works, even if it doesn't actually upload newly written data to the GL vbo.

There are two other ways to deal with this:
*) Switch into single buffer mode, but keep the sysmem copy around without ever
using it. Lock() then returns different addresses in various locks, but the
first address stays valid.
*) Create the VBO before before or during the first lock. That way the locked
address points somewhere into opengl's memory, and this address range happens
to stay accessible after the unlock, destroying the buffer and reinitializing
the GL context during Reset(). This also prevents the crash, but there's no
guarantee for that. This approach also causes graphic corruption - either
because some unrelated bug, or because the game runs amok in OpenGL's data,
overwriting other vertex buffer contents.

In short, the game is broken, period. Rico's patch isn't really an option
because it doubles memory use of vertex buffers. This makes well-behaved games
run worse on low memory machines and makes other games(Team Fortess 2, Left 4
Dead for example) crash because of address space exhaustion.

I'm afraid there's no chance that Crysis will ever be fixed. Crytek apparently
stopped supporting the game in 2008, and back then the conventional wisdom was
that the game was buggy beyond repair. What we can do at best is to put Rico's
hack into wine and enable it only conditionally(e.g. via registry key).

There is one other possibility: That a different bug in Wine triggers a broken
codepath in Crysis, and Crysis doesn't actually perform the same broken memory
access on Windows. A potential candidate would be some refcounting issue, as it
is quite remarkable that the crash happens quite a while after the buffer has
been used the last time. I have not found any evidence for a refcounting issuue
however.

The d3d10 codepath of the game may also not have this bug, so implementing
d3d10 may be a possible clean fix for owners of d3d10 capable cards.

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