https://bugs.winehq.org/show_bug.cgi?id=53010
Bug ID: 53010 Summary: Split/Second crashes on launch Product: Wine Version: 7.2 Hardware: x86-64 URL: https://download.cnet.com/Split-Second-demo/3000-7513_ 4-75206464.html OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: winepulse.drv Assignee: wine-bugs@winehq.org Reporter: andrey.goosev@gmail.com CC: gabrielopcode@gmail.com Regression SHA1: 1ccdbcf475e21a9320dc81e0b0acac7fd997f338 Distribution: ---
wine: Unhandled exception 0xc0000409 in thread 15c at address 03A7A721 (thread 015c), starting debugger...
https://bugs.winehq.org/show_bug.cgi?id=53010
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- FWIW, 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN Can you pinpoint the commit that caused the regression?
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- EDIT: Never mind, am too tired... Sorry for the noise.
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #3 from Gabriel Ivăncescu gabrielopcode@gmail.com --- I am unable to reproduce this bug. For me the game works perfectly fine (even started the demo race which worked). I also have 3 physical audio devices (one PCI and two USB), which somewhat rules out game choking on more than one I think.
Can you please attach a log with +pulse,+mmdevapi,+seh,+unwind,+debugstr,+loaddll
Depending how early the crash happens, +relay might also help.
It would also be nice to have the user.reg/system.reg from your wineprefix (so I can look at your recognized devices by PA and so on); if you feel it contains private information you'd rather not disclose, you can email it to me instead.
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #4 from Andrey Gusev andrey.goosev@gmail.com --- Created attachment 72384 --> https://bugs.winehq.org/attachment.cgi?id=72384 log
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #5 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 72387 --> https://bugs.winehq.org/attachment.cgi?id=72387 Debugging log hack
I tried to hack my devices list to report exactly the same as your log, and I still can't reproduce it, unfortunately. The game also has anti-debugging. That said, I managed to understand what triggers the crash, but not sure *why* it happens in your case.
So, the game sets up a cookie on the stack, just before the exception handler. The cookie is taken from some global variable. It then calls a bunch of ole and mmdevapi functions, and returns. Just before it returns, it checks the cookie to see if it matches with the global value. In my case it always matches, so it works fine.
In your case, it seems the cookie does not match, and then it calls a function that quits with STATUS_STACK_BUFFER_OVERRUN. This is a standard stack protection since it assumes something overwrote past the end of a buffer and changed the cookie.
I've attached a debugging hack which prints the cookie on each function called by the game's fmodex.dll within that problematic part in your log. Please make sure to compile wine with the normal -fno-omit-frame-pointer (if you messed with it) because otherwise it will crash and not output anything useful. It should at least show after which point the cookie gets modified.
There's also the possibility it doesn't get modified at all, but the global value changes, and at least this will make it known.
Note that this patch isn't supposed to fix it, it just attempts to print the cookie, so the game crashing at the same spot is a good thing when you run it.
Please compile wine git with this debugging hack and run it with +ole,+pulse,+mmdevapi,+seh,+unwind,+debugstr,+loaddll
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #6 from Andrey Gusev andrey.goosev@gmail.com --- Created attachment 72388 --> https://bugs.winehq.org/attachment.cgi?id=72388 hack output
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #7 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 72393 --> https://bugs.winehq.org/attachment.cgi?id=72393 Trace device names
So fmodex.dll used by the game can't handle Friendly Device Names with more than 62 characters + NUL. (DEVPKEY_Device_FriendlyName, DEVPKEY_DeviceInterface_FriendlyName, DEVPKEY_Device_DeviceDesc props)
I've sent a patch to the mailing list. Does the following patch (link) help?
https://source.winehq.org/patches/data/236327
Note that the attached diff here is for something else that I'm wondering about. I noticed your device names have some weird data at the end; not sure if that's a bug somewhere else (in PA?), which is why they are so long to begin with.
Can you please try the attached patch and post a log with +pulse? You can try it on top of the one I linked from the mailing list, it doesn't matter if it crashes or not, just want to see why the name is so weird.
But that's not really important to fix this particular bug, it's just something extra. Because I tested with a normal artificial name and it crashes if it's > 62 chars in length.
The linked patch from the mailing list should stop the crash though.
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- 62 is a weird number. Are you sure there's no memory corruption when using 62 characters? Or is it just that it doesn't crash?
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #9 from Gabriel Ivăncescu gabrielopcode@gmail.com --- (In reply to Fabian Maurer from comment #8)
62 is a weird number. Are you sure there's no memory corruption when using 62 characters? Or is it just that it doesn't crash?
Not entirely certain, but it's the point at which it doesn't crash, yes. I did look at the disassembled parts, although I haven't been able to use a debugger (including winedbg) because it instantly quits (it has anti-debugging hacks).
I can see it makes space for a 64-byte buffer, but in this buffer it places the ASCII converted string. It does a dumb conversion by skipping every 2nd byte from the wide string. 62 isn't *entirely* weird, considering a 64-length buffer holds 63 characters at most (since last one is NUL). It is weird in some sense since it's 1 character less than 63, though, so I can see what you mean.
That said, if we limit the buffer to 32 characters (that will 100% fit in the converted buffer it makes space for), that's way too low in my opinion. A lot of legitimate devices have longer names than this, especially in PA where you have "Monitor of ..." sources.
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #10 from Andrey Gusev andrey.goosev@gmail.com --- Created attachment 72417 --> https://bugs.winehq.org/attachment.cgi?id=72417 +pulse
(In reply to Gabriel Ivăncescu from comment #7)
https://bugs.winehq.org/show_bug.cgi?id=53010
--- Comment #11 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Thanks, it looks like the "Analog Stereo" part reported by PA at the end is in Ukrainian, so it's expected, just the name of the device is very long in total. No bug at least.
https://bugs.winehq.org/show_bug.cgi?id=53010
temp82@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |temp82@luukku.com
--- Comment #12 from temp82@luukku.com --- (In reply to Andrey Gusev from comment #0)
wine: Unhandled exception 0xc0000409 in thread 15c at address 03A7A721 (thread 015c), starting debugger...
Andrey is this fixed now for you in current git? https://source.winehq.org/patches/data/236926
got merged.
https://bugs.winehq.org/show_bug.cgi?id=53010
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |ccc9f1d2ce23c8fbb3059934f82 | |079692e04e49c
--- Comment #13 from Andrey Gusev andrey.goosev@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commit/ccc9f1d2ce23c8fbb3059934f82079...
https://bugs.winehq.org/show_bug.cgi?id=53010
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.10.
-
WineHQ Bugzilla