[Bug 53010] New: Split/Second crashes on launch
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(a)winehq.org Reporter: andrey.goosev(a)gmail.com CC: gabrielopcode(a)gmail.com Regression SHA1: 1ccdbcf475e21a9320dc81e0b0acac7fd997f338 Distribution: --- wine: Unhandled exception 0xc0000409 in thread 15c at address 03A7A721 (thread 015c), starting debugger... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #1 from Fabian Maurer <dark.shadow4(a)web.de> --- FWIW, 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN Can you pinpoint the commit that caused the regression? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #2 from Fabian Maurer <dark.shadow4(a)web.de> --- EDIT: Never mind, am too tired... Sorry for the noise. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #3 from Gabriel Ivăncescu <gabrielopcode(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #4 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Created attachment 72384 --> https://bugs.winehq.org/attachment.cgi?id=72384 log -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #5 from Gabriel Ivăncescu <gabrielopcode(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #6 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Created attachment 72388 --> https://bugs.winehq.org/attachment.cgi?id=72388 hack output -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #7 from Gabriel Ivăncescu <gabrielopcode(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #8 from Fabian Maurer <dark.shadow4(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #9 from Gabriel Ivăncescu <gabrielopcode(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #10 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Created attachment 72417 --> https://bugs.winehq.org/attachment.cgi?id=72417 +pulse (In reply to Gabriel Ivăncescu from comment #7) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 --- Comment #11 from Gabriel Ivăncescu <gabrielopcode(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 temp82(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |temp82(a)luukku.com --- Comment #12 from temp82(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 Andrey Gusev <andrey.goosev(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |ccc9f1d2ce23c8fbb3059934f82 | |079692e04e49c --- Comment #13 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Fixed by https://source.winehq.org/git/wine.git/commit/ccc9f1d2ce23c8fbb3059934f82079... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=53010 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 7.10. -- 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.
participants (1)
-
WineHQ Bugzilla