https://bugs.winehq.org/show_bug.cgi?id=41998
Bug ID: 41998 Summary: Regression in wined3d crashes visual novel "A drug that makes you dream" Product: Wine Version: 1.9.24 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: dark.shadow4@web.de CC: hverbeet@gmail.com Regression SHA1: 4a9304305ae2940288e9382926a6931dd46982d5 Distribution: ArchLinux
Created attachment 56422 --> https://bugs.winehq.org/attachment.cgi?id=56422 Crashlog
Commit in question: 4a9304305ae2940288e9382926a6931dd46982d5 Author: Henri Verbeet hverbeet@codeweavers.com Date: Tue Mar 29 16:45:33 2016 +0200
wined3d: Simplify checking if the released resource is in use as a rendertarget in device_resource_released().
Signed-off-by: Henri Verbeet hverbeet@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
Patch doesn't revert cleanly, so I couldn't test reversing the commit.
The last lines before the crash seem interesting. Wine seems to still use the device, later crashes in "device_resource_released" at "device->fb.render_targets[i]", because "render_targets" is NULL. Also, "device->ref" is 44003456, what can't be.
https://bugs.winehq.org/show_bug.cgi?id=41998
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Created attachment 56423 --> https://bugs.winehq.org/attachment.cgi?id=56423 Hack to get it to work
A dirty hack to get the game running.
https://bugs.winehq.org/show_bug.cgi?id=41998
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #2 from Henri Verbeet hverbeet@gmail.com --- The patch lost the "device->d3d_initialized" condition, which could be problematic for ddraw applications. Restoring that seems likely to help.
For completeness, could you attach a +seh,+tid,+ddraw,+d3d log? What I expect to happen is that the application messes up its reference counting in some way, as ddraw applications are known to do, and then we make it worse by trying to clean up on ddraw unload.
44003456 is 0x29f7080, which looks suspiciously like a heap address. Does warn+heap make a difference?
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Created attachment 56433 --> https://bugs.winehq.org/attachment.cgi?id=56433 WINEDEBUG=warn+heap
WINEDEBUG=warn+heap doesn't make a big difference, but notice that it doesn't try to access NULL anymore, it's now a different address.
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #4 from Fabian Maurer dark.shadow4@web.de --- Created attachment 56434 --> https://bugs.winehq.org/attachment.cgi?id=56434 WINEDEBUG=+seh,+tid,+ddraw,+d3d
Added trace for "WINEDEBUG=+seh,+tid,+ddraw,+d3d".
https://bugs.winehq.org/show_bug.cgi?id=41998
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia@gmail.com
--- Comment #5 from Józef Kucia joseph.kucia@gmail.com --- (In reply to Fabian Maurer from comment #3)
Created attachment 56433 [details] WINEDEBUG=warn+heap
WINEDEBUG=warn+heap doesn't make a big difference, but notice that it doesn't try to access NULL anymore, it's now a different address.
0xfeeefeee is a bit pattern used by "warn+heap" to mark free blocks.
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #6 from Henri Verbeet hverbeet@gmail.com --- Created attachment 56493 --> https://bugs.winehq.org/attachment.cgi?id=56493 patch
So this patch fixes it, right?
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #7 from Fabian Maurer dark.shadow4@web.de --- Created attachment 56498 --> https://bugs.winehq.org/attachment.cgi?id=56498 Crash log with path
Sadly not. The issue seems to go deeper. The crash in "device_resource_released" is gone, but "resource_cleanup" later calls "wined3d_cs_emit_destroy_object" where "cs->ops->require_space" seems to be called.
The exception "illegal instruction in 32-bit code" indicates that this pointer is invalid.
New backtrack attached.
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #8 from Henri Verbeet hverbeet@gmail.com --- (In reply to Fabian Maurer from comment #7)
Created attachment 56498 [details] Crash log with path
Sadly not. The issue seems to go deeper.
Right, at the core the issue is that ddraw releases the wined3d device before all the corresponding resources are released. That's what the "Device released with resources still bound ..." messages is about, and it's not a new issue. The "acceptable" in that message may be a bit misleading at this point.
I had hoped avoiding the issue in device_resource_released() would have been enough to fix this for 2.0, but it looks like there are more issues.
https://bugs.winehq.org/show_bug.cgi?id=41998
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #56493|0 |1 is obsolete| |
--- Comment #9 from Henri Verbeet hverbeet@gmail.com --- Created attachment 56683 --> https://bugs.winehq.org/attachment.cgi?id=56683 patch
How about this patch?
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #10 from Fabian Maurer dark.shadow4@web.de --- Created attachment 56687 --> https://bugs.winehq.org/attachment.cgi?id=56687 Log for second patch
Basically still the same error. It crashes in "resource_cleanup".
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #11 from Henri Verbeet hverbeet@gmail.com --- Could you create a +seh,+tid,+ddraw,+d3d log with that patch?
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #12 from Fabian Maurer dark.shadow4@web.de --- Created attachment 56688 --> https://bugs.winehq.org/attachment.cgi?id=56688 Log with second patch (+seh,+tid,+ddraw,+d3d)
I don't quite know why, but when WINEDEBUG includes +d3d, then it crashes in "process_rtl_work_item" instead of "resource_cleanup"...
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #13 from Henri Verbeet hverbeet@gmail.com --- Does warn+heap help with that?
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #14 from Fabian Maurer dark.shadow4@web.de --- No, quite the contrary. If either "+d3d" or "warn+heap" is added to WINEDEBUG, it crashes in "process_rtl_work_item" instead of "resource_cleanup".
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #15 from Henri Verbeet hverbeet@gmail.com --- (In reply to Fabian Maurer from comment #14)
No, quite the contrary. If either "+d3d" or "warn+heap" is added to WINEDEBUG, it crashes in "process_rtl_work_item" instead of "resource_cleanup".
That may not be a bad thing, could you add warn+heap and attach the log here?
https://bugs.winehq.org/show_bug.cgi?id=41998
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #56688|0 |1 is obsolete| |
--- Comment #16 from Fabian Maurer dark.shadow4@web.de --- Created attachment 56689 --> https://bugs.winehq.org/attachment.cgi?id=56689 Log for second patch (+seh,+tid,+ddraw,+d3d,warn+heap)
It has a single warn:heap message.
https://bugs.winehq.org/show_bug.cgi?id=41998
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #56683|0 |1 is obsolete| |
--- Comment #17 from Henri Verbeet hverbeet@gmail.com --- Created attachment 56703 --> https://bugs.winehq.org/attachment.cgi?id=56703 patch
New patch. Does this one work any better?
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #18 from Fabian Maurer dark.shadow4@web.de --- Yes, this new patch fixes the crash and makes the game fully work.
Note that it also removes the "Device released with resources still bound, acceptable but unexpected." "Leftover resource 0x2a2d668 with type WINED3D_RTYPE_TEXTURE_2D (0x2)." fixemes in wined3d_device_decref.
https://bugs.winehq.org/show_bug.cgi?id=41998
--- Comment #19 from Fabian Maurer dark.shadow4@web.de --- Fixed since 9a789feb81f49c75b168d1f6a6406b2ede74cb1d
https://bugs.winehq.org/show_bug.cgi?id=41998
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |9a789feb81f49c75b168d1f6a64 | |06b2ede74cb1d Resolution|--- |FIXED
--- Comment #20 from Henri Verbeet hverbeet@gmail.com --- Reported fixed.
https://bugs.winehq.org/show_bug.cgi?id=41998
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 2.0-rc4.