[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: wine-bugs(a)winehq.org Reporter: maxitg(a)icloud.com 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-.... -- 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=43966 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tspamm3r(a)gmail.com --- Comment #1 from Ken Thomases <ken(a)codeweavers.com> --- *** Bug 43975 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.
https://bugs.winehq.org/show_bug.cgi?id=43966 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- 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=43966 vitormm(a)portingkit.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vitormm(a)portingkit.com --- Comment #2 from vitormm(a)portingkit.com --- 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...). -- 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=43966 --- Comment #3 from VitorMM <vitormm(a)portingkit.com> --- (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. -- 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=43966 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Ken Thomases <ken(a)codeweavers.com> --- 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. -- 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=43966 --- Comment #5 from VitorMM <vitormm(a)portingkit.com> --- 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? -- 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=43966 marbaquero(a)yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marbaquero(a)yahoo.com --- Comment #6 from marbaquero(a)yahoo.com --- (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? -- 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=43966 --- Comment #7 from Ken Thomases <ken(a)codeweavers.com> --- (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. -- 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=43966 --- Comment #8 from VitorMM <vitormm(a)portingkit.com> --- (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. -- 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=43966 --- Comment #9 from Ken Thomases <ken(a)codeweavers.com> --- (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. -- 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=43966 --- Comment #10 from marbaquero(a)yahoo.com --- (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? -- 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=43966 --- Comment #11 from VitorMM <vitormm(a)portingkit.com> --- 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 :) -- 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=43966 --- Comment #12 from marbaquero(a)yahoo.com --- (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. -- 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=43966 --- Comment #13 from VitorMM <vitormm(a)portingkit.com> --- (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. -- 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=43966 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gijsvrm(a)gmail.com --- Comment #14 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- 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 -- 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=43966 --- Comment #15 from VitorMM <vitormm(a)portingkit.com> --- (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? -- 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=43966 --- Comment #16 from Ken Thomases <ken(a)codeweavers.com> --- (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? -- 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=43966 --- Comment #17 from VitorMM <vitormm(a)portingkit.com> --- (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? -- 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=43966 --- Comment #18 from VitorMM <vitormm(a)portingkit.com> --- 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* -- 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=43966 Thierry <thierry(a)theremin.tf> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thierry(a)theremin.tf --- Comment #19 from Thierry <thierry(a)theremin.tf> --- 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. -- 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=43966 --- Comment #20 from VitorMM <vitormm(a)portingkit.com> --- (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. -- 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=43966 --- Comment #21 from Thierry <thierry(a)theremin.tf> --- (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... -- 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=43966 --- Comment #22 from Austin English <austinenglish(a)gmail.com> --- (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. -- 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=43966 --- Comment #23 from Thierry <thierry(a)theremin.tf> --- 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. -- 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=43966 --- Comment #24 from Thierry <thierry(a)theremin.tf> --- 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!!! :-) -- 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=43966 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #25 from Ken Thomases <ken(a)codeweavers.com> --- (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. -- 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=43966 --- Comment #26 from marbaquero(a)yahoo.com --- yes, definitely, new update works! -- 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=43966 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #27 from Matteo Bruni <matteo.mystral(a)gmail.com> --- (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. -- 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)
-
wine-bugs＠winehq.org