[Bug 58755] New: 16 bit skifree does not work under wow64
http://bugs.winehq.org/show_bug.cgi?id=58755 Bug ID: 58755 Summary: 16 bit skifree does not work under wow64 Product: Wine Version: 10.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: edoardo762(a)gmail.com Distribution: --- I saw that wine 10.16 in WOW64 now supports 16 bit programs, so i tried the original skifree, but it is crashing with this trace 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 0138:err:environ:init_peb starting L"C:\\windows\\syswow64\\winevdm.exe" in experimental wow64 mode 013c:err:seh:call_seh_handlers invalid frame 000000000103EBA0 (00007FFFFE302000-00007FFFFE3FFD20) 013c:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. The application can be downloaded from https://ski.ihoc.net/ (the link for the 16 bit version is at the bottom) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Edoardo Lolletti <edoardo762(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|16 bit skifree does not |16 bit SkiFree does not |work under wow64 |work under wow64 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rjqxqqnhuibvkxkshx(a)ytnhy.co | |m --- Comment #1 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- *** Bug 58762 has been marked as a duplicate of this bug. *** -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #2 from Edoardo Lolletti <edoardo762(a)gmail.com> --- I tester other win16 games from here (https://www.classicdosgames.com/win16.html) and from my collection, some KF them work, others exhibit the same crash. For example 3d ultra pinball works (the file you download from the site is a self extracting zip archive), but bang bang crashes in the same way as SkiFree. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #3 from Bob <rjqxqqnhuibvkxkshx(a)ytnhy.com> --- The original 16-bit Windows 3.1 version of SkiFree can be downloaded directly from the Internet Archive: https://archive.org/details/win3_WINSKI -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> --- I'm afraid I can't reproduce that, it works fine here. This may be something that depends on the CPU or kernel version. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Alexandre Julliard from comment #4)
I'm afraid I can't reproduce that, it works fine here. This may be something that depends on the CPU or kernel version.
I can confirm that the application crashes during very first CallTo16 call in new wow64 build while it works in old wow64 in the same Wine prefix. What kind of logs could help to diagnose the reason of the 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- We can try +seh. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #7 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Created attachment 79404 --> http://bugs.winehq.org/attachment.cgi?id=79404 +relay,+seh log Here's a +relay,+seh log, hopefully it's small enough. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #8 from Zeb Figura <z.figura12(a)gmail.com> --- I actually ended up partially debugging this. The problem is that Wine sometimes does WCB16_REGS calls with a zeroed context, so it sets zero %fs and %gs. Some CPUs crash when %gs is zero even in 64-bit mode, mine included. With debugging, this happens at the second instruction of the unix call dispatcher, which loads from %gs. Without debugging, it still crashes, this time in the process of trying to call NtSetLdtEntries() called from InitTask(). On my machine it doesn't actually crash in the syscall dispatcher, but rather when loading the TEB in free_temp_data() called from Wow64SystemServiceEx(), which my compiler for some reason decides to do before calling wow64_syscall(). The effect is the same. What's confusing is that we shouldn't have a cleared %gs in 32-bit code, because we save and restore the 32-bit %gs when calling into and out of 16-bit code. I'm not sure what's going wrong with that mechanism. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #9 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Zeb Figura from comment #8)
I actually ended up partially debugging this. The problem is that Wine sometimes does WCB16_REGS calls with a zeroed context, so it sets zero %fs and %gs. Some CPUs crash when %gs is zero even in 64-bit mode, mine included.
Okay, it's more complicated than that. It turns out: * the kernel lies to us: FS_sig and GS_sig are always zero in an exception, but that's not their real values. This threw me off. * %gs being zero is fine actually; in fact it seems to be zero to start out with. The problem is that clearing %gs, in some processors, also seems to clear gsbase. This is observed in the ntdll:exception tests. * %gs is cleared when calling into 16-bit code. Its previous value is restored when calling back into 32-bit code, which we do before doing any syscalls or unix calls, but this doesn't help, because this either doesn't affect gsbase, or clears it again. [Plus, the previous value was zero for me.] * 94447cee61 is supposed to catch broadly this. It doesn't catch the unix call case (or the syscall case) because it tries to read the faulting instruction with virtual_handle_fault(), but here the faulting instruction isn't in a PE module. We can special-case those safely, I think. * 94447cee61 *does*, as one might predict, catch the case I mentioned where we fault in wow64cpu.dll. However the game still doesn't launch, and I'm not sure why. I see a subsequent SEGV from the game doing an int21, but for some reason that exception doesn't seem to even reach the PE side of ntdll. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #10 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Zeb Figura from comment #9)
* 94447cee61 is supposed to catch broadly this. It doesn't catch the unix call case (or the syscall case) because it tries to read the faulting instruction with virtual_handle_fault(), but here the faulting instruction isn't in a PE module. We can special-case those safely, I think.
I've submitted 9122 for this.
* 94447cee61 *does*, as one might predict, catch the case I mentioned where we fault in wow64cpu.dll. However the game still doesn't launch, and I'm not sure why. I see a subsequent SEGV from the game doing an int21, but for some reason that exception doesn't seem to even reach the PE side of ntdll.
Scratch this, I was somehow on an old branch despite what I thought. This part works fine with upstream Wine. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|16 bit SkiFree does not |16-bit applications crash |work under wow64 |under new wow64 on some | |processors -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #11 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Zeb Figura from comment #10)
(In reply to Zeb Figura from comment #9)
* 94447cee61 is supposed to catch broadly this. It doesn't catch the unix call case (or the syscall case) because it tries to read the faulting instruction with virtual_handle_fault(), but here the faulting instruction isn't in a PE module. We can special-case those safely, I think.
I've submitted 9122 for this.
This patch fixes the problem for me, now 16-bit SKI.EXE runs with new wow64 build for me, thanks! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #12 from Edoardo Lolletti <edoardo762(a)gmail.com> --- Created attachment 79412 --> http://bugs.winehq.org/attachment.cgi?id=79412 log I'm trying to build wine 10.16 with the patch from the mr applied, but can't seem to be able to build it as I'm getting compile errors. Attached is the output, this is how i'm configuring wine ``` ../configure --prefix=/tmp/wine-pref --libdir=/tmp/wine-pref/lib --enable-archs=x86_64,i386 --disable-tests --without-oss --without-sane --without-v4l2 --without-cups --without-gphoto --without-xinerama --without-pcsclite --without-xxf86vm --without-pcap --without-wayland ``` and i'm building with make -j13 I'm on arch, using the distro provided mingw (13.0.0-1) and gcc (15.2.0) packages -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 --- Comment #13 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Zeb Figura from comment #8)
I actually ended up partially debugging this. The problem is that Wine sometimes does WCB16_REGS calls with a zeroed context, so it sets zero %fs and %gs. Some CPUs crash when %gs is zero even in 64-bit mode, mine included.
Thank you for looking into this! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mumei6102(a)gmail.com --- Comment #14 from Zeb Figura <z.figura12(a)gmail.com> --- *** Bug 58760 has been marked as a duplicate of this bug. *** -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |fd6bdbeda50c2871ad5f80bb1b0 | |824244f73cf01 Resolution|--- |FIXED --- Comment #15 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Zeb Figura from comment #10)
(In reply to Zeb Figura from comment #9)
* 94447cee61 is supposed to catch broadly this. It doesn't catch the unix call case (or the syscall case) because it tries to read the faulting instruction with virtual_handle_fault(), but here the faulting instruction isn't in a PE module. We can special-case those safely, I think.
I've submitted 9122 for this.
The MR was merged as fd6bdbeda50c2871ad5f80bb1b0824244f73cf01. Thanks Zeb! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll -- 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.
http://bugs.winehq.org/show_bug.cgi?id=58755 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #16 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.17. -- 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