http://bugs.winehq.org/show_bug.cgi?id=18824
Summary: Thief 3 broken since 1.1.19 by commit to wined3d Product: Wine Version: 1.1.19 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: michael@araneidae.co.uk CC: stefan@codeweavers.com
Created an attachment (id=21628) --> (http://bugs.winehq.org/attachment.cgi?id=21628) Log of Thief 3 scrash
The following commit causes Thief 3 to crash on starting a new game:
commit 014c4bfc70a4d4e60f033d579d1be13a46f65170 Author: Stefan Dösinger stefan@codeweavers.com Date: Thu Apr 9 18:40:57 2009 +0200
wined3d: Save some memory in vertex buffers.
To reproduce (on this commit), start t3.exe, escape past all the start screens, and press START NEW GAME (if you can read it!) Crash log attached.
Note that at the best of time Thief 3 generates a lot of crashes, both in game (presumably cut scenes failing to launch?) and on exit, but at least it was semi-playable.
There is a Thief 3 demo.
http://bugs.winehq.org/show_bug.cgi?id=18824
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|Thief 3 broken since 1.1.19 |Thief 3 crashes when |by commit to wined3d |starting a new game
http://bugs.winehq.org/show_bug.cgi?id=18824
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #1 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-07 21:50:21 --- Can you attach a +d3d,+d3d9 log?
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #2 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-07 21:55:15 --- did you try this with an up to date wine version by the way? This patch introduced 2 problems that were fixed since then.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #3 from Michael Abbott michael@araneidae.co.uk 2009-06-08 03:20:02 --- Thanks for changing the title to something sensible!
I'll add a +d3d,+d3d9 log tonight, but wanted to say first of all that I reproduced this bug on the following released versions (as a quick manual bisect before performing the git bisect between 1.1.18 and 1.1.19): 1.1.19, 1.1.20, 1.1.23. I haven't tried current git, but .23 is pretty fresh, so I expect the bug is current.
I've also confirmed the bug with the Thief 3 demo with .23.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #4 from Rico kgbricola@web.de 2009-06-08 09:28:01 --- I want to confirm this bug with the demo (http://www.eidos.de/downloads/search.html?gmid=174).
My system specifications: Fedora 10 (2.6.27.24-170.2.68.fc10.x86_64) Geforce 8800GTS (NVIDIA 180.44) wine 1.1.23
What are your specs?
Also note this game is d3d8 (or do I have the wrong one?), at least I got some segfaults in IDirect3DDevice8Impl_DeletePixelShader() even before the problematic patch, but the game runs fine with them (but that's probably another problem).
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #5 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-08 10:45:09 --- Do the DeletePixelShader crashes still occur with the broken Wine versions(ie, the ones with the vertex buffer patch)? If yes, they may corrupt memory or an Unlock() call may be skipped that causes follow up problems.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #6 from Rico kgbricola@web.de 2009-06-08 10:56:29 --- No, the crash from the regression is earlier than the crash from the DeletePixelShader call.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #7 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-08 11:14:52 --- ok, still need a log then. +d3d,+d3d8 if its a d3d8 game
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #8 from Rico kgbricola@web.de 2009-06-08 11:23:18 --- Created an attachment (id=21650) --> (http://bugs.winehq.org/attachment.cgi?id=21650) +d3d,+d3d8 log
This is a +d3d,+d3d8 log from the thief demo crash. It crashes after a call to trace:d3d:buffer_Map Returning memory at 0xfbe0 (*base (nil)*, offset 64480), which isn't the case on a run before the regression. There are only calls with a base address (the log is ~1,1GB). I don't know if that has something to do with the problem.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #9 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-08 11:32:26 --- "*base (nil)*" doesn't sound right. That means the glMapBuffer call fails.
I don't know what to do with this right away. The question is if the failing glMapBuffer is a symptom or the cause of the problem. If it is a symptom, it will take a while to find what's really wrong. If it is the cause, we could catch the error and fall back to the behavior before the patch for the buffers where MapBuffer fails.
I need some more info: *) Are there any gl errors or out of memory errors before the crash? *) What graphics card and driver are you using?
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #10 from Michael Abbott michael@araneidae.co.uk 2009-06-08 11:33:15 --- Created an attachment (id=21651) --> (http://bugs.winehq.org/attachment.cgi?id=21651) Crash log with WINEDEBUG=+d3d,+d3d8
Sorry, the log file is pretty big. Fortunately bzip2 was able to bring it within reach.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #11 from Michael Abbott michael@araneidae.co.uk 2009-06-08 11:35:24 --- (In reply to comment #10)
Crash log with WINEDEBUG=+d3d,+d3d8
Forgot to say: this log was created with wine 1.1.23 on Ubuntu 9.04 with an nVidia GeForce 9400 GT graphics card and an otherwise pretty standard Ubuntu configuration.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #12 from Rico kgbricola@web.de 2009-06-08 11:38:27 --- My specs are at http://bugs.winehq.org/show_bug.cgi?id=18824#c4 ;-) and I couldn't see any gl errors (they have to be in the log, if there where any).
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #13 from Rico kgbricola@web.de 2009-06-08 11:49:52 --- I've added a fixme after the count=InterlockedIncrement(&This->lock_count); with the result:
fixme:d3d:buffer_Map ###########count 1 fixme:d3d:buffer_Map ###########count 0 fixme:d3d:buffer_Map ###########count -96
huh?
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #14 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-08 11:59:05 --- Yep, something seems to go wrong in the buffer. Can you add some logs to buffer_map to see if it enters the glMapBuffer path, or the path that uses the self-allocated This->resouce.allocatedMemory?
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #15 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-08 12:16:42 --- Can you check if there are any Unmap calls without a Map() call? That's probably supposed to return an error, but we do not check for this condition yet. If the buffer is unlocked without being locked, the lockcount gets negative, and since it is an unsigned value that's a pretty large positive value. Prior to my patch this probably kept the buffer working normally, maybe the GL buffer wasn't updated properly, but no crash should occur. Now with the glMapBuffer calls that means a NULL buffer data pointer and a crash.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #16 from Rico kgbricola@web.de 2009-06-08 12:21:57 --- Created an attachment (id=21652) --> (http://bugs.winehq.org/attachment.cgi?id=21652) output of the map calls
This log contains a trace of map and unmap calls.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #17 from Rico kgbricola@web.de 2009-06-08 12:25:15 ---
Can you check if there are any Unmap calls without a Map() call?
Yes, that's the case.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #18 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-08 12:31:43 --- Try to return WINED3DERR_INVALIDCALL if unmap is called without map
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #19 from Rico kgbricola@web.de 2009-06-08 12:42:36 --- Created an attachment (id=21653) --> (http://bugs.winehq.org/attachment.cgi?id=21653) Workaround for number of calls to Unmap > Map
This patch adds a check to Unmap to make sure the counter isn't decremented too much on too many calls to Unmap. This works fine for the thief demo here.
(It doesn't solve the problem with crysis - that was expected - see bug 18799 .)
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #20 from Stefan Dösinger stefandoesinger@gmx.at 2009-06-08 12:48:42 --- Make the ERR a WARN, write a small test in dlls/d3d9/tests/, and you're good to go to send it to wine-patches. There is as far as I can see no test file for buffer tests, so its probably a good idea to start a new one. Just copypaste the device creation code from e.g. vertexdeclaration.c
If you're extra ambitious you can port the test to ddraw, d3d8 and d3d10core to see if the behavior is the same. I guess ddraw might need an adjustment for the return value(e.g. WINED3DERR_INVALIDCALL -> D3DERR_INVALIDPARAMS).
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #21 from Rico kgbricola@web.de 2009-06-08 13:01:24 --- I'll write a test and send it (it could take a while).
@Michael Could you try the patch (http://bugs.winehq.org/attachment.cgi?id=21653)?
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #22 from Michael Abbott michael@araneidae.co.uk 2009-06-08 15:00:02 --- (In reply to comment #21)
@Michael Could you try the patch (http://bugs.winehq.org/attachment.cgi?id=21653)?
Yes, seems to work now, at least as well as it ever did.
Bugs 6971 and 9688 remain blockers, and it spins off crashes between every scene, but I guess that's all off topic here.
http://bugs.winehq.org/show_bug.cgi?id=18824
--- Comment #23 from Rico kgbricola@web.de 2009-06-12 06:46:45 --- Should be fixed by commit 3ea66d6026a208f5fc551cd9a5bb421d2adfa4e3.
http://bugs.winehq.org/show_bug.cgi?id=18824
Michael Abbott michael@araneidae.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #24 from Michael Abbott michael@araneidae.co.uk 2009-06-12 17:09:46 --- Can I mark this as fixed, then?
http://bugs.winehq.org/show_bug.cgi?id=18824
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Alexandre Julliard julliard@winehq.org 2009-06-19 11:09:27 --- Closing bugs fixed in 1.1.24.
http://bugs.winehq.org/show_bug.cgi?id=18824
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |3ea66d6026a208f5fc551cd9a5b | |b421d2adfa4e3 CC| |focht@gmx.net Component|-unknown |directx-d3d
--- Comment #26 from Anastasius Focht focht@gmx.net 2012-01-01 10:50:55 CST --- Hello,
filling fields ...
Regards
-
wine-bugs＠winehq.org