[Bug 58755] New: 16 bit skifree does not work under wow64

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
      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)

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Edoardo Lolletti  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|16 bit skifree does not     |16 bit SkiFree does not
                   |work under wow64            |work under wow64

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |m

--- Comment #1 from Dmitry Timoshkov  ---
*** Bug 58762 has been marked as a duplicate of this bug. ***

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #2 from Edoardo Lolletti  ---
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.

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #3 from Bob  ---
The original 16-bit Windows 3.1 version of SkiFree can be downloaded directly
from the Internet Archive:
https://archive.org/details/win3_WINSKI

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #4 from Alexandre Julliard  ---
I'm afraid I can't reproduce that, it works fine here. This may be something
that depends on the CPU or kernel version.

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #5 from Dmitry Timoshkov  ---
(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?

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #6 from Alexandre Julliard  ---
We can try +seh.

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #7 from Dmitry Timoshkov  ---
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.

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Zeb Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #8 from Zeb Figura  ---
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.

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #9 from Zeb Figura  ---
(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.

[Bug 58755] 16 bit SkiFree does not work under wow64

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #10 from Zeb Figura  ---
(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.

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Zeb Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|16 bit SkiFree does not     |16-bit applications crash
                   |work under wow64            |under new wow64 on some
                   |                            |processors

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #11 from Dmitry Timoshkov  ---
(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!

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #12 from Edoardo Lolletti  ---
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

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

--- Comment #13 from Alexandre Julliard  ---
(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!

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Zeb Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #14 from Zeb Figura  ---
*** Bug 58760 has been marked as a duplicate of this bug. ***

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Fixed by SHA1|                            |fd6bdbeda50c2871ad5f80bb1b0
                   |                            |824244f73cf01
         Resolution|---                         |FIXED

--- Comment #15 from Dmitry Timoshkov  ---
(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!

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|-unknown                    |ntdll

[Bug 58755] 16-bit applications crash under new wow64 on some processors

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58755

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #16 from Alexandre Julliard  ---
Closing bugs fixed in 10.17.