Bug 231010
| Summary: | emulators/wine: Segmentation fault when built on 12.0-CURRENT/ALPHA | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Theron Tarigo <theron.tarigo> | ||||||
| Component: | Individual Port(s) | Assignee: | Gerald Pfeifer <gerald> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | dbn, dim, doctorwhoguy, gerald, iwtcex, markj, sbruno, theron.tarigo, toolchain | ||||||
| Priority: | --- | Keywords: | crash | ||||||
| Version: | Latest | Flags: | gerald:
merge-quarterly-
|
||||||
| Hardware: | amd64 | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
|
Description
Theron Tarigo
2018-08-29 20:29:43 UTC
I can, of course, add USE_GCC=yes to emulators/wine, but it would be preferable to see what clang does here. I tried compiling wine using WITH_DEBUG, but the backtrace doesn't really give much information at all:
(gdb) r
Starting program: /usr/local/bin/wine64 /usr/local/bin/notepad
process 21271 is executing new program: /usr/local/bin/wine64
Program received signal SIGSEGV, Segmentation fault.
0x000000017b448f40 in ?? ()
(gdb) bt
#0 0x000000017b448f40 in ?? ()
#1 0x000000007bc37691 in __wine_process_init () at loader.c:3362
#2 0x00000000621e4294 in wine_init (argc=1023, argv=0x7fffffffe401, error=<optimized out>, error_size=1024) at loader.c:979
#3 0x0000000060000338 in main (argc=2, argv=0x7fffffffe4d0) at main.c:258
(gdb) up
#1 0x000000007bc37691 in __wine_process_init () at loader.c:3362
3362 init_func();
(gdb) l
3357 0, (void **)&init_func )) != STATUS_SUCCESS)
3358 {
3359 MESSAGE( "wine: could not find __wine_kernel_init in kernel32.dll, status %x\n", status );
3360 exit(1);
3361 }
3362 init_func();
3363 }
It seems the crash is caused by init_func being garbage, but no idea why. This will probably take some time to look into.
It turns out to be that the *.dll.so are broken; the Wine loader (__wine_process_init) does work. How I have determined this: Where "12x build" is Wine 3.0.2 port built on FreeBSD 12.0-ALPHA Where "11x build" is Wine 3.0.2 port built on FreeBSD 11.2-RELEASE - Installing the 12x build produces a broken (segfaulting) installation. - Installing the 12x build, but replacing all /usr/local/lib/wine/* from 11x build, produces a working installation. - Installing the 11x build produces a working installation. - Installing the 11x build, but replacing the single file /usr/local/lib/wine/kernel32.dll.so with the one from the 12x build, produces a broken (segfaulting) installation. kernel32.dll.so is the first object to be loaded, so replacing it alone is sufficient to break the installation. However, using a good kernel32.dll.so but replacing other *.dll.so with those from the 12x build also causes the problem, so kernel32.dll.so is not the only one affected. > Using USE_GCC=yes works around the problem, but using LLD_UNSAFE=yes with the default toolchain produces broken binaries with the same symptom.
Remove /usr/bin/ld -> /usr/bin/ld.lld symlink and try USE_BINUTILS=yes.
Created attachment 200749 [details]
lld_unsafe=yes & winegcc fix
In case you don't find messing with symlinks appealing.
(In reply to Alex S from comment #5) On further testing, while Clang + ld.bfd works for running winecfg/winemine/regedit, actually complex applications (Witcher 3, Wolfenstein TNO) keep crashing somewhere. GCC 8 works fine. (In reply to Alex S from comment #6) +1, I had to add USE_GCC=yes to get it working. So, should we go with USE_GCC=yes simply? Wine upstream is built and tested (and shipped) built with GCC. (In reply to Gerald Pfeifer from comment #8) Wine was previously working (partially) with LLVM toolchain, but seeing as how a change there can break it entirely, it might also be true that the toolchain is the cause of some of the lesser and otherwise inexplicable failures of WINE that are particular to FreeBSD. Since Wine already uses GCC internally (as far as I can tell?) and is tested with it upstream, USE_GCC=yes makes the most sense. For comparison: Does Wine on Darwin use Apple's LLVM, or does it require GCC port there as well? (In reply to Gerald Pfeifer from comment #8) > So, should we go with USE_GCC=yes simply? Unfortunately, yes. (In reply to Theron Tarigo from comment #9) > some of the lesser and otherwise inexplicable failures of WINE If you have the time, you could probably make quite a bit of impact by running Wine's unit tests and reporting FreeBSD-specific failures upstream. Afaik, nobody runs those tests [on FreeBSD] even on a semi-regular basis. > Since Wine already uses GCC internally (as far as I can tell?) No, winegcc is just a wrapper. (In reply to Theron Tarigo from comment #9) > Wine was previously working (partially) with LLVM toolchain, but seeing > as how a change there can break it entirely, it might also be true that > the toolchain is the cause of some of the lesser and otherwise inexplicable > failures of WINE that are particular to FreeBSD. Indeed. It's yet another factor/difference that introduces risk in a very complex and hard to duplicate/assess situation. (In reply to Alex S from comment #10) > No, winegcc is just a wrapper. Yes, but GCC appears to be the compiler used by (nearly) all Wine developers and the one used to the commercial Crossover products. So, here is what I'll do: I'll add an option to this port such that the user can choose whether to use GCC or not (in which case it'll be the system compiler). And I'll make the use of GCC the default. That is the conservative option for non-expert users, while giving an option to those who want to avoid GCC - plus an easy way to play with the two compiler choices. (Adding @dbn, who made the original suggestion to go for clang where available back a few years ago, and since he's been more than just helping with things around Wine on FreeBSD over the years.) A commit references this bug: Author: gerald Date: Mon Jan 21 01:12:28 UTC 2019 New revision: 490816 URL: https://svnweb.freebsd.org/changeset/ports/490816 Log: Add a new option, GCC, that controls the use of GCC instead of the system compiler (usually clang these days) as we have been doing since r334935 in 2013-11-26. And make that the default, both since there've been user reports about Wine not working properly with the toolchain in FreeBSD 12 and there may be other challenges given that upstream and in other distributions GCC is being used all along. [1] Also backport part of r488645 | gerald | 2018-12-29 01:53:56 from emulators/wine-devel: Create a proper USES block in Makefile, moving the existing USES statement there. PR: 231010 [1] Changes: head/emulators/wine/Makefile (In reply to commit-hook from comment #12) It looks like this got reverted for more testing. Can I get the same thing applied to wine-devel as well? I'm more interested in wine-staging at the moment. Created attachment 201339 [details] Proposed patch (updated) for emulators/wine (In reply to Sean Bruno from comment #13) > It looks like this got reverted for more testing. > > Can I get the same thing applied to wine-devel as well? I'm more > interested in wine-staging at the moment. Yes and yes. I am planning to apply the attached patch by the end of the week. If you can test and let me know how it works for you (especially in packing the desired compilers) that'd be cool (In reply to Gerald Pfeifer from comment #14) Variant of the same patch works for wine-devel. Thanks. A commit references this bug: Author: gerald Date: Fri Jan 25 14:04:40 UTC 2019 New revision: 491148 URL: https://svnweb.freebsd.org/changeset/ports/491148 Log: Restore a simpler and more elegant version of r490816 which was reverted in r490825. (r490827 addresses the breakage of INDEX which happened in some scenarios that led to that revert.) Add a new option, GCC, that controls the use of GCC instead of the system compiler (usually clang these days) as we have been doing since r334935 in 2013-11-26. And make that the default, both since there've been user reports about Wine not working properly with the toolchain in FreeBSD 12 and since there may be other challenges given that upstrea and in other distributions GCC is being used all along. PR: 231010 Reviewed by: mat Tested by: sbruno Changes: head/emulators/wine/Makefile A commit references this bug: Author: gerald Date: Thu Jan 31 09:51:28 UTC 2019 New revision: 491699 URL: https://svnweb.freebsd.org/changeset/ports/491699 Log: Update to Wine 4.0, the actual release, with essentially no real changes from the last RC. This will shortly move to the main emulators/wine port, but let's give it a bit of time and wider exposure first. Forward port r491148 | gerald | 2019-01-25: Add a new option, GCC, that controls the use of GCC instead of the system compiler (usually clang these days) as we have been doing since r334935 in 2013-11-26. And make that the default, both since there've been user reports about Wine not working properly with the toolchain in FreeBSD 12 and since there may be other challenges given that both upstream and in other distributions GCC is being used all along. [1] PR: 231010 [1] Reviewed by: mat [1] Tested by: sbruno [1] Changes: head/emulators/wine-devel/Makefile head/emulators/wine-devel/distinfo I think we have thusly addressed both emulators/wine as well as emulators/wine-devel which is what Sean was after (for the support of the Staging patchset). |
