[Bug 43966] New: Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Bug ID: 43966
           Summary: Wine crashes at launch in macOS 10.13.2 Beta (17C60c)
           Product: Wine
           Version: 2.20
          Hardware: x86-64
                OS: Mac OS X
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]

Wine crashes immediately after launch in macOS 10.13.2 Beta (17C60c). Running
either "winecfg", "winedbg", or even "wine someString", produces the following
output:

i386_set_ldt: Invalid argument
Segmentation fault: 11

Apparently, the behavior of i386_set_ldt has changed in 10.13.2, so the call to
it at /libs/wine/ldt.c line 209 fails with errno = 22 (EINVAL).

The issue did not exist in macOS 10.13.1, however, I was able to reproduce it
with another computer running 10.13.2 and clean (first time) Wine installation.

This could be a macOS bug (especially since it's a beta), but I thought it
would make sense to post it here as well.

The issue is related to
https://forums.eveonline.com/t/client-closed-unexpectedly-cannot-launch-the-....

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Ken Thomases  changed:

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

--- Comment #1 from Ken Thomases  ---
*** Bug 43975 has been marked as a duplicate of this bug. ***

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Austin English  changed:

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

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

[e-mail] changed:

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

--- Comment #2 from [e-mail] ---
Seen that here as well. Same macOS version, on a SSD, with the new Apple
filesystem APFS (not sure if that's relevant, but still...).

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #3 from VitorMM  ---
(In reply to VitorMM from comment #2)
> Seen that here as well. Same macOS version, on a SSD, with the new Apple
> filesystem APFS (not sure if that's relevant, but still...).

Also, I tried launching three different Wine prefixes: two using Mac Driver
(one with vanilla Wine and one with Staging Wine) and one using X11 (vanilla
Wine). None of them worked.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Ken Thomases  changed:

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

--- Comment #4 from Ken Thomases  ---
Yeah, this is just a bug in the OS. The i386_set_ldt() system call is necessary
for Wine's initialization of threads in 32-bit processes. That system call has
narrowed the range of valid indexes it accepts and the new range doesn't
include those that Wine tries to use.

CodeWeavers has discussed it with Apple. At this point, we expect them to fix
it before 10.13.2 is released.

If they don't there is a workaround of just changing the definition of
LDT_FIRST_ENTRY in Wine.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #5 from VitorMM  ---
So we first need to find out where is the reserve entries end? There is any way
to figure that out, or just by trying a bunch of different values?

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

[e-mail] changed:

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

--- Comment #6 from [e-mail] ---
(In reply to Ken Thomases from comment #4)
> Yeah, this is just a bug in the OS. The i386_set_ldt() system call is
> necessary for Wine's initialization of threads in 32-bit processes. That
> system call has narrowed the range of valid indexes it accepts and the new
> range doesn't include those that Wine tries to use.
>
> CodeWeavers has discussed it with Apple. At this point, we expect them to
> fix it before 10.13.2 is released.
>
> If they don't there is a workaround of just changing the definition of
> LDT_FIRST_ENTRY in Wine.

Hi there,

I just installed the new update from apple 10.13.2 Beta (17C67b), and
unfortunately it does not solve the i386_set_ldt issue.

However in my case, I can run the native wine.app version 1.8.4, with no
problems. I only get the i386_set_ldt: Invalid argument Segmentation fault:
when I manually run "startwine" from the acestream.app package.

Thoughts?

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #7 from Ken Thomases  ---
(In reply to Ken Thomases from comment #4)
> CodeWeavers has discussed it with Apple. At this point, we expect them to
> fix it before 10.13.2 is released.

On re-reading this, it may be unclear. To clarify: I work for CodeWeavers. So
the "we" was CodeWeavers and the "them" was Apple. We at CodeWeavers expect
that Apple will fix this.

(In reply to VitorMM from comment #5)
> So we first need to find out where is the reserve entries end? There is any
> way to figure that out, or just by trying a bunch of different values?

The range supported by the OS before 10.13.2 is from 3 to 8191. The range in
the 10.13.2 betas is 3 to 127. I wrote a simple test program to determine this.

Wine currently tries indexes from 512 to 8191. (It assumes that indexes below
512 are reserved for the system.)

(In reply to marbaquero from comment #6)
> However in my case, I can run the native wine.app version 1.8.4, with no
> problems. I only get the i386_set_ldt: Invalid argument Segmentation fault:
> when I manually run "startwine" from the acestream.app package.

I have no idea what "the acestream.app package" is, nor what you're actually
doing with Wine 1.8.4. Note that this problem only affects 32-bit processes. If
you are working with a 64-bit prefix and 64-bit programs (including Wine's
built-in programs like Notepad or Winecfg), then it won't happen.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #8 from VitorMM  ---
(In reply to Ken Thomases from comment #7)
> (In reply to VitorMM from comment #5)
> > So we first need to find out where is the reserve entries end? There is any
> > way to figure that out, or just by trying a bunch of different values?
>
> The range supported by the OS before 10.13.2 is from 3 to 8191. The range in
> the 10.13.2 betas is 3 to 127. I wrote a simple test program to determine
> this.
>
> Wine currently tries indexes from 512 to 8191. (It assumes that indexes
> below 512 are reserved for the system.)

So these lines from libs/wine/ldt.c
#define LDT_FIRST_ENTRY 512
#define LDT_SIZE 8192

Should instead be like for macOS?
#define LDT_FIRST_ENTRY 3
#define LDT_SIZE 127

Just to confirm.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #9 from Ken Thomases  ---
(In reply to VitorMM from comment #8)
> So these lines from libs/wine/ldt.c
> #define LDT_FIRST_ENTRY 512
> #define LDT_SIZE 8192
>
> Should instead be like for macOS?
> #define LDT_FIRST_ENTRY 3
> #define LDT_SIZE 127
>
> Just to confirm.

Yes, basically. I wouldn't bother changing LDT_SIZE. If Wine tries values past
what the OS supports, it will just fail in a slightly different way than if it
knows it has exhausted the limit. Either way, that would only affect processes
with many threads.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #10 from [e-mail] ---
(In reply to Ken Thomases from comment #7)
> (In reply to Ken Thomases from comment #4)
> > CodeWeavers has discussed it with Apple. At this point, we expect them to
> > fix it before 10.13.2 is released.
>
> On re-reading this, it may be unclear. To clarify: I work for CodeWeavers.
> So the "we" was CodeWeavers and the "them" was Apple. We at CodeWeavers
> expect that Apple will fix this.
>
> (In reply to VitorMM from comment #5)
> > So we first need to find out where is the reserve entries end? There is any
> > way to figure that out, or just by trying a bunch of different values?
>
> The range supported by the OS before 10.13.2 is from 3 to 8191. The range in
> the 10.13.2 betas is 3 to 127. I wrote a simple test program to determine
> this.
>
> Wine currently tries indexes from 512 to 8191. (It assumes that indexes
> below 512 are reserved for the system.)
>
> (In reply to marbaquero from comment #6)
> > However in my case, I can run the native wine.app version 1.8.4, with no
> > problems. I only get the i386_set_ldt: Invalid argument Segmentation fault:
> > when I manually run "startwine" from the acestream.app package.
>
> I have no idea what "the acestream.app package" is, nor what you're actually
> doing with Wine 1.8.4. Note that this problem only affects 32-bit processes.
> If you are working with a 64-bit prefix and 64-bit programs (including
> Wine's built-in programs like Notepad or Winecfg), then it won't happen.

=============================================================================

Here is my situation:

I have been running Acestream with wine on my mac for awhile now, without any
problems, however since I upgraded to MacOS High Sierra 10.13.2 Beta (17C60c),
the Acestream engine just refuses to start. (I assume you are familiar with
Acestream?)

I kept troubleshooting yesterday, and I found out that when I start Wine (for
mac) by itself (wine.app), it starts fine, and the current prefix is .wine,

When I execute the windows file Ace_Stream_Media_3.1.16.1.exe

the wine GUI appears, I click Go, but nothing happens, ACE does not start.

No matter what I do, i always get this error  i386_set_ldt: Invalid argument

It seems the way to solve this, is for me to revert back to 10.13.1

Thoughts?

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #11 from VitorMM  ---
Confirming: the method mentioned above works. I could create a wine prefix with
Wine Staging 2.20 and install Steam in it after replacing this:
#define LDT_FIRST_ENTRY 512
#define LDT_SIZE 8192

With this:
#define LDT_FIRST_ENTRY 3
#define LDT_SIZE 127

Thanks to Ken Thomases for finding the workaround for the bug and to Gijs
Vermeulen for compiling Wine with the change so I could test it :)

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #12 from [e-mail] ---
(In reply to VitorMM from comment #11)
> Confirming: the method mentioned above works. I could create a wine prefix
> with Wine Staging 2.20 and install Steam in it after replacing this:
> #define LDT_FIRST_ENTRY 512
> #define LDT_SIZE 8192
>
> With this:
> #define LDT_FIRST_ENTRY 3
> #define LDT_SIZE 127
>
> Thanks to Ken Thomases for finding the workaround for the bug and to Gijs
> Vermeulen for compiling Wine with the change so I could test it :)

This is great, when can we download this patch?. Which version of wine should I
use for this?

Thanks.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #13 from VitorMM  ---
(In reply to marbaquero from comment #12)
> This is great, when can we download this patch?. Which version of wine
> should I use for this?
>
> Thanks.

It's exactly like I described. He haven't created a patch, just replaced the
values of the two define's in libs/wine/ldt.c

Technically, I think it should work with any Wine version as long as those
variables exist. By 2003 they existed already, except that LDT_FIRST_ENTRY was
WINE_LDT_FIRST_ENTRY, and it was located in a different file.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Gijs Vermeulen  changed:

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

--- Comment #14 from Gijs Vermeulen  ---
Created attachment 59647
  --> https://bugs.winehq.org/attachment.cgi?id=59647
Hack/Workaround (Thanks Ken!)

(In reply to marbaquero from comment #12)
> This is great, when can we download this patch?. Which version of wine
> should I use for this?
>
> Thanks.

You can build wine yourself with this patch applied.
See: https://wiki.winehq.org/Regression_Testing#Patching_your_git_tree
and https://wiki.winehq.org/MacOS/Building

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #15 from VitorMM  ---
(In reply to Ken Thomases from comment #9)
> Yes, basically. I wouldn't bother changing LDT_SIZE. If Wine tries values
> past what the OS supports, it will just fail in a slightly different way
> than if it knows it has exhausted the limit. Either way, that would only
> affect processes with many threads.

But isn't it going to give a faster answer if it exhausts the limit instead of
waiting until it receives a system error/warning/exception?

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #16 from Ken Thomases  ---
(In reply to VitorMM from comment #15)
> (In reply to Ken Thomases from comment #9)
> > Yes, basically. I wouldn't bother changing LDT_SIZE. If Wine tries values
> > past what the OS supports, it will just fail in a slightly different way
> > than if it knows it has exhausted the limit. Either way, that would only
> > affect processes with many threads.
>
> But isn't it going to give a faster answer if it exhausts the limit instead
> of waiting until it receives a system error/warning/exception?

"Faster answer"? In either case, the failure would only happen at the time of
the attempt to create the 125th thread or whatever. If the call to
i386_set_ldt() fails because you let Wine try a too-high index, then you get
the "i386_set_ldt: Invalid argument" message and probably an access violation
immediately afterward.

If you change LDT_SIZE so that Wine doesn't even try the too-high index, then
CreateThread()/CreateRemoteThread()/RtlCreateUserThread() returns an error
status code. The caller may or may not actually check the return value. If it
doesn't, then it just goes on assuming the thread was created when it wasn't.
There may or may not be immediately obvious consequences, including log
messages.

In any case, this should just be a temporary hack for a beta version of the OS.
It's not terribly important exactly how it fails, is it?

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #17 from VitorMM  ---
(In reply to Ken Thomases from comment #16)
> "Faster answer"? In either case, the failure would only happen at the time
> of the attempt to create the 125th thread or whatever. If the call to
> i386_set_ldt() fails because you let Wine try a too-high index, then you get
> the "i386_set_ldt: Invalid argument" message and probably an access
> violation immediately afterward.
>
> If you change LDT_SIZE so that Wine doesn't even try the too-high index,
> then CreateThread()/CreateRemoteThread()/RtlCreateUserThread() returns an
> error status code. The caller may or may not actually check the return
> value. If it doesn't, then it just goes on assuming the thread was created
> when it wasn't. There may or may not be immediately obvious consequences,
> including log messages.

Well, technically that's something that should be something handled by the
application, and not by Wine :P

If I understood correctly, the access violation isn't going to be received by
the Windows application. Instead, this will crash Wine due to the access
violation, or not?
> In any case, this should just be a temporary hack for a beta version of the
> OS. It's not terribly important exactly how it fails, is it?

Well, Wine doesn't even launch without that change, and considering that Apple
may not change that, leaving those as the real parameters for macOS, this may
become more than a temporary hack :P

Also, if the Windows application fails to create the thread, it may find a way
to handle it if it was properly programmed. If Wine receives an access
violation, there is no way that this should be properly handled in order to
proceed using the application, or I misunderstood the consequences of the
access violation?

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #18 from VitorMM  ---
Fixing some typos in my last message:

technically that's something that should be handled by the application*

there is no way to handle that properly to proceed using the application*

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Thierry  changed:

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

--- Comment #19 from Thierry  ---
Err... and if I'm not able to recompile WINE on my own, but am depending on the
PlayOnMac/PlayOnLinux people to update the WINE versions which they bundle with
their tools? I think that winehq should publish an official bug fix update
(2.20a) so that third party companies who bundle WINE within their stuff were
more motivated to adopt it.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #20 from VitorMM  ---
(In reply to Thierry from comment #19)
> Err... and if I'm not able to recompile WINE on my own, but am depending on
> the PlayOnMac/PlayOnLinux people to update the WINE versions which they
> bundle with their tools? I think that winehq should publish an official bug
> fix update (2.20a) so that third party companies who bundle WINE within
> their stuff were more motivated to adopt it.

I guess they haven't done that yet because, technically, it isn't official yet.
Apple haven't released a stable version of macOS 10.3.2 with that bug, only
Beta versions.

By the way, marbaquero told me and I can confirm: the bug is still present in
the Public Beta 2 (17C67b). That makes two Beta versions of macOS with the bug.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #21 from Thierry  ---
(In reply to VitorMM from comment #20)
> (In reply to Thierry from comment #19)
> > Err... and if I'm not able to recompile WINE on my own, but am depending on
> > the PlayOnMac/PlayOnLinux people to update the WINE versions which they
> > bundle with their tools? I think that winehq should publish an official bug
> > fix update (2.20a) so that third party companies who bundle WINE within
> > their stuff were more motivated to adopt it.
>
> I guess they haven't done that yet because, technically, it isn't official
> yet. Apple haven't released a stable version of macOS 10.3.2 with that bug,
> only Beta versions.
>
> By the way, marbaquero told me and I can confirm: the bug is still present
> in the Public Beta 2 (17C67b). That makes two Beta versions of macOS with
> the bug.

Interesting, the developer beta has the same version number (17C67b). Waiting
for the beta 3...

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #22 from Austin English  ---
(In reply to Thierry from comment #19)
> Err... and if I'm not able to recompile WINE on my own, but am depending on
> the PlayOnMac/PlayOnLinux people to update the WINE versions which they
> bundle with their tools? I think that winehq should publish an official bug
> fix update (2.20a) so that third party companies who bundle WINE within
> their stuff were more motivated to adopt it.

Wine releases development versions every two weeks, but as Ken pointed out,
this is Apple's bug and Wine is expecting them to fix it. That could be
revisited if Apple makes this change in a stable release.

You could ask PlayOnMac to make a binary version with the hack applied. They
apply plenty of other patches, so I don't see why they couldn't apply this one.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #23 from Thierry  ---
Apple just published macOS High Sierra 10.13.2 beta 3. Currently downloading
and hoping that the LDT bug will be fixed. Will report back later.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #24 from Thierry  ---
macOS 10.13.2 beta 3 fixes the issue (or restores the expected behavior).
Launched just a few Win32 apps in PlayOnMac and everything works again!!! :-)

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Ken Thomases  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTOURBUG

--- Comment #25 from Ken Thomases  ---
(In reply to Thierry from comment #24)
> macOS 10.13.2 beta 3 fixes the issue (or restores the expected behavior).
> Launched just a few Win32 apps in PlayOnMac and everything works again!!! :-)

Thanks for letting us know.  I can confirm that beta 3 fixes it.

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

--- Comment #26 from [e-mail] ---
yes, definitely, new update works!

[Bug 43966] Wine crashes at launch in macOS 10.13.2 Beta (17C60c)

https://bugs.winehq.org/show_bug.cgi?id=43966

Matteo Bruni  changed:

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

--- Comment #27 from Matteo Bruni  ---
(In reply to Thierry from comment #24)
> macOS 10.13.2 beta 3 fixes the issue (or restores the expected behavior).
> Launched just a few Win32 apps in PlayOnMac and everything works again!!! :-)

Closing fixed third-party bug.