Bug 231010 - emulators/wine: Segmentation fault when built on 12.0-CURRENT/ALPHA
Summary: emulators/wine: Segmentation fault when built on 12.0-CURRENT/ALPHA
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Gerald Pfeifer
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2018-08-29 20:29 UTC by Theron Tarigo
Modified: 2019-01-31 10:34 UTC (History)
9 users (show)

See Also:
gerald: merge-quarterly-


Attachments
lld_unsafe=yes & winegcc fix (1.21 KB, patch)
2019-01-03 21:20 UTC, Alex S
koobs: maintainer-approval? (gerald)
Details | Diff
Proposed patch (updated) for emulators/wine (1.50 KB, patch)
2019-01-22 18:40 UTC, Gerald Pfeifer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Theron Tarigo 2018-08-29 20:29:43 UTC
Wine built from ports on 12.0-CURRENT/ALPHA is unable to run, instead segfaulting on startup.

Using USE_GCC=yes works around the problem, but using LLD_UNSAFE=yes with the default toolchain produces broken binaries with the same symptom.  However, Wine is working with the default toolchain on 11.2-RELEASE, showing that GCC shouldn't be needed.  Furthermore, copying a Wine build from 11.2-RELEASE to the 12.0 system results in usable Wine.

This seems to implicate the FreeBSD 12.0 toolchain.
Comment 1 Gerald Pfeifer freebsd_committer 2018-09-01 20:37:36 UTC
I can, of course, add USE_GCC=yes to emulators/wine, but it would be
preferable to see what clang does here.
Comment 2 Dimitry Andric freebsd_committer 2018-09-01 21:50:31 UTC
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.
Comment 3 Theron Tarigo 2018-09-03 20:29:33 UTC
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.
Comment 4 Alex S 2019-01-02 23:28:42 UTC
> 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.
Comment 5 Alex S 2019-01-03 21:20:12 UTC
Created attachment 200749 [details]
lld_unsafe=yes & winegcc fix

In case you don't find messing with symlinks appealing.
Comment 6 Alex S 2019-01-06 13:16:46 UTC
(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.
Comment 7 Mark Johnston freebsd_committer 2019-01-06 19:38:54 UTC
(In reply to Alex S from comment #6)
+1, I had to add USE_GCC=yes to get it working.
Comment 8 Gerald Pfeifer freebsd_committer 2019-01-19 21:52:52 UTC
So, should we go with USE_GCC=yes simply?

Wine upstream is built and tested (and shipped) built with GCC.
Comment 9 Theron Tarigo 2019-01-19 23:00:09 UTC
(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?
Comment 10 Alex S 2019-01-20 04:48:05 UTC
(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.
Comment 11 Gerald Pfeifer freebsd_committer 2019-01-20 20:28:06 UTC
(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.)
Comment 12 commit-hook freebsd_committer 2019-01-21 01:13:01 UTC
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
Comment 13 Sean Bruno freebsd_committer 2019-01-22 18:29:50 UTC
(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.
Comment 14 Gerald Pfeifer freebsd_committer 2019-01-22 18:40:23 UTC
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
Comment 15 Sean Bruno freebsd_committer 2019-01-22 19:04:03 UTC
(In reply to Gerald Pfeifer from comment #14)
Variant of the same patch works for wine-devel.  Thanks.
Comment 16 commit-hook freebsd_committer 2019-01-25 14:05:40 UTC
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
Comment 17 commit-hook freebsd_committer 2019-01-31 09:51:38 UTC
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
Comment 18 Gerald Pfeifer freebsd_committer 2019-01-31 10:34:15 UTC
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).