[Bug 49437] New: Segmentation fault (core dumped) even on winecfg or wineconsole on FreeBSD
https://bugs.winehq.org/show_bug.cgi?id=49437
Bug ID: 49437 Summary: Segmentation fault (core dumped) even on winecfg or wineconsole on FreeBSD Product: Wine Version: 5.11 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: adrien_fernandes2@hotmail.com
For the moment, I stick with wine-5.8 which is actually perfectly working for me.
Since wine-5.9, it won't run anymore. It builds, it installs but it won't start and I really have no other message than "Segmentation fault (core dumped)" I build wine without any patch in case this creates the issue (already happened a few months ago). All information I succeeded to have is by using WINEDEBUG=all
trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x7ffe0000 00001000 3000 00000002 Segmentation fault (core dumped)
That's all I get and I don't even know if it's related to the problem.
https://bugs.winehq.org/show_bug.cgi?id=49437
Sean C. Farley sean-freebsd@farley.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sean-freebsd@farley.org
--- Comment #1 from Sean C. Farley sean-freebsd@farley.org --- I have also seen this with an i386 build of Wine 5.11 on FreeBSD.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #2 from Sean C. Farley sean-freebsd@farley.org --- This still occurs with i386 builds of Wine 5.12 and 5.13.
https://bugs.winehq.org/show_bug.cgi?id=49437
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #3 from Damjan Jovanovic damjan.jov@gmail.com --- I contribute to Wine from FreeBSD, and building from source (NOT port, ie. no patches), these are the results I got with my i386 build:
5.6 was working 5.7 crash on startup due to #49139 5.8 crash on startup due to #49139 5.9 #49139 was fixed, but still crashed sometimes due to #49225 (which was itself a fix for another FreeBSD-only bug) 5.10 #49225 also fixed, works for me 5.11 works for me, the #49139 fix was also ported to FreeBSD CURRENT (I used 12.1 in my tests)
Note that some of these fixes were backported into ports prior to being accepted upstream, so some of the broken versions here might still work if you installed from ports.
I'll do more testing with the latest master ASAP, it's quite possible other regressions were introduced with the many NTDLL changes recently.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #4 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Damjan Jovanovic from comment #3)
I contribute to Wine from FreeBSD, and building from source (NOT port, ie. no patches), these are the results I got with my i386 build:
5.6 was working 5.7 crash on startup due to #49139 5.8 crash on startup due to #49139 5.9 #49139 was fixed, but still crashed sometimes due to #49225 (which was itself a fix for another FreeBSD-only bug) 5.10 #49225 also fixed, works for me 5.11 works for me, the #49139 fix was also ported to FreeBSD CURRENT (I used 12.1 in my tests)
Note that some of these fixes were backported into ports prior to being accepted upstream, so some of the broken versions here might still work if you installed from ports.
I'll do more testing with the latest master ASAP, it's quite possible other regressions were introduced with the many NTDLL changes recently.
The latest Git works for me too, even on a clean WINEPREFIX.
Wine 5.10 (or 5.11 if you're on CURRENT) and later should all work.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #5 from Sean C. Farley sean-freebsd@farley.org --- Created attachment 67808 --> https://bugs.winehq.org/attachment.cgi?id=67808 ktrace of winecfg execution
I am running 12.1-STABLE r363031 amd64 (r363017 was the last commit within the tree I am running). This has the patch you submitted to FreeBSD for #49139.
Wine was built from ports in an i386 jail using an edited emulators/i386-wine-devel port to build later versions than currently in ports for it. It only uses two patches from the emulators/wine-devel port located here: https://svnweb.freebsd.org/ports/head/emulators/wine-devel/files/ The only patch that affects the run of Wine would be patch-dlls_kernel32_Makefile.in.
This is the only difference between my running system and changes to anything within libexec/rtld-elf: https://svnweb.freebsd.org/base/stable/12/libexec/rtld-elf/rtld.c?r1=363372&...
I am attaching the failure at the end of a ktrace when attempting to run winecfg. There is an "mmap -1 errno 22 Invalid argument" right before opening ntdll.dll.so. Interestingly, the first ktrace showed code=SEGV_MAPERR while all other runs (at least 20) showed code=SEGV_ACCERR.
Just checking, are you testing amd64, i386 or i386 on amd64? I had just noticed that Adrien, who opened this issue, had labeled the hardware as x86-64 (amd64), so something may be amiss with my setup compared to his.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #6 from Adrien Fernandes adrien_fernandes2@hotmail.com --- My actual FreeBSD is this one : FreeBSD 13.0-CURRENT #0 r362292: Thu Jun 18 04:59:33 UTC 2020 amd64
I didn't update FreeBSD yet. Still having the same issue on wine-5.13.
I build wine using a i386 chrooted environment, not building through ports BUT still applying manually the patches from emulator/wine-devel.
It builds fine, installs as well but still the same Segmentation fault on 5-13. So I should update FreeBSD if I want to use >wine-5.8 ?
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #7 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Adrien Fernandes from comment #6)
My actual FreeBSD is this one : FreeBSD 13.0-CURRENT #0 r362292: Thu Jun 18 04:59:33 UTC 2020 amd64
CURRENT's rtld-elf's behavior changed, so if you run CURRENT, please make sure it's recent enough. This command has to print something; if not, you may on the "bad" patch of CURRENT when Wine mistranslated load addresses (as it had no way to tell what type of address rtld-elf used):
nm -D /libexec/ld-elf.so.1 | grep _rtld_version_laddr_offset
(This is not an issue for pre-CURRENT versions, despite returning no output.)
I didn't update FreeBSD yet. Still having the same issue on wine-5.13.
I build wine using a i386 chrooted environment, not building through ports BUT still applying manually the patches from emulator/wine-devel.
It builds fine, installs as well but still the same Segmentation fault on 5-13. So I should update FreeBSD if I want to use >wine-5.8 ?
Other than that I am really not sure. Your best bet is probably to "git bisect", but there could be several working and half-working versions in between. I can try provide a change timeline and some specific commits to try, which might give us some preliminary answers?
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #8 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Sean C. Farley from comment #5)
Created attachment 67808 [details] ktrace of winecfg execution
I am running 12.1-STABLE r363031 amd64 (r363017 was the last commit within the tree I am running). This has the patch you submitted to FreeBSD for #49139.
Wine was built from ports in an i386 jail using an edited emulators/i386-wine-devel port to build later versions than currently in ports for it. It only uses two patches from the emulators/wine-devel port located here: https://svnweb.freebsd.org/ports/head/emulators/wine-devel/files/ The only patch that affects the run of Wine would be patch-dlls_kernel32_Makefile.in.
This is the only difference between my running system and changes to anything within libexec/rtld-elf: https://svnweb.freebsd.org/base/stable/12/libexec/rtld-elf/rtld. c?r1=363372&r2=363371&pathrev=363372
I am attaching the failure at the end of a ktrace when attempting to run winecfg. There is an "mmap -1 errno 22 Invalid argument" right before opening ntdll.dll.so. Interestingly, the first ktrace showed code=SEGV_MAPERR while all other runs (at least 20) showed code=SEGV_ACCERR.
This might be something:
56486 wine CALL mmap(0,0x1000,0<PROT_NONE>,0x1012<MAP_PRIVATE|MAP_FIXED|MAP_ANON>,0xffffffff,0,0) 56486 wine RET mmap -1 errno 22 Invalid argument
I can't find such a line in my own ktrace, and MAP_FIXED shouldn't really be getting used much on FreeBSD without MAP_EXCL.
Just checking, are you testing amd64, i386 or i386 on amd64? I had just noticed that Adrien, who opened this issue, had labeled the hardware as x86-64 (amd64), so something may be amiss with my setup compared to his.
i386 on amd64
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #9 from Sean C. Farley sean-freebsd@farley.org --- Created attachment 67895 --> https://bugs.winehq.org/attachment.cgi?id=67895 gdb output of segfault
I compiled with gcc v9.3.0 and installed Wine v5.14 manually with debugging (-ggdb3) to see if I could figure out what is happening. Here is the trace of it crashing at the start of __wine_process_init() in dlls/ntdll/loader.c. This is the same crash whether it is i386 or amd64 for me. This trace is the amd64 build.
Configuration was this: CC=gcc9 CXX=g++9 LDFLAGS="-ggdb3 -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9" CFLAGS="-ggdb3 -pipe -Wl,-rpath=/usr/local/lib/gcc9 -isystem /usr/local/include" ./configure --verbose --with-oss --with-x --with-cms --with-fontconfig --with-freetype --with-glu --with-jpeg --with-opengl --with-png --with-xinerama --with-xinput2 --with-xrandr --with-xrender --enable-win64 --libdir=/tmp/wine/local/lib --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/tmp/wine/local
Side note: I was unable to get the system clang (v10.0.1) so used the compiler that the port uses to compile wine.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #10 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Sean C. Farley from comment #9)
Created attachment 67895 [details] gdb output of segfault
I compiled with gcc v9.3.0 and installed Wine v5.14 manually with debugging (-ggdb3) to see if I could figure out what is happening. Here is the trace of it crashing at the start of __wine_process_init() in dlls/ntdll/loader.c. This is the same crash whether it is i386 or amd64 for me. This trace is the amd64 build.
Configuration was this: CC=gcc9 CXX=g++9 LDFLAGS="-ggdb3 -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9" CFLAGS="-ggdb3 -pipe -Wl,-rpath=/usr/local/lib/gcc9 -isystem /usr/local/include" ./configure --verbose --with-oss --with-x --with-cms --with-fontconfig --with-freetype --with-glu --with-jpeg --with-opengl --with-png --with-xinerama --with-xinput2 --with-xrandr --with-xrender --enable-win64 --libdir=/tmp/wine/local/lib --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/tmp/wine/local
Please post the contents of your /proc/PID/map when that breakpoint gets hit, so we can compare the address in your kernel32_start_process variable against those address ranges.
Side note: I was unable to get the system clang (v10.0.1) so used the compiler that the port uses to compile wine.
Clang hasn't worked for building Wine properly, for quite a while ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231010).
Also there is some other notes in that bug report, such as WITH_DEBUG breaking Wine in a similar way to what you're seeing.
https://bugs.winehq.org/show_bug.cgi?id=49437
Alex S iwtcex@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iwtcex@gmail.com
--- Comment #11 from Alex S iwtcex@gmail.com --- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=218779&action=diff#e... ;)
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #12 from Alex S iwtcex@gmail.com --- (In reply to Alex S from comment #11)
You, guys, are no fun at all. All crashes there are caused by Wine being compiled in a chroot/jail with headers prior to https://reviews.freebsd.org/rS361349. I mean, the commit message blatantly states "Restore the binary compatibility for link_map l_addr", those binaries still receive an uncorrected address when run on a newer host (l_addr in the old struct defintion = l_base in the new definition). Thus, the _rtld_version_laddr_offset check is not appropriate here.
https://bugs.winehq.org/show_bug.cgi?id=49437
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
https://bugs.winehq.org/show_bug.cgi?id=49437
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #13 from Damjan Jovanovic damjan.jov@gmail.com --- I am pretty sure I figured this out after 2 days of git bisect, after Wine on FreeBSD 12.2 started crashing non-stop while 12.1 worked.
The attempt by FreeBSD developers to preserve binary compatibility didn't go too well. To quote from my patch:
/* l_addr changed meaning from absolute load address (which is now l_base) * to relocation offset, but also got moved within the struct, breaking * the ABI via struct layout change: * * OLD header: NEW header: * typedef struct link_map { typedef struct link_map { * caddr_t l_addr; caddr_t l_base; * ... ... * ... caddr_t l_addr; * }; }; * * OLD ld-elf.so: NEW ld-elf.so: * ... exports _rtld_version_laddr_offset * * Since the header change and rtld change aren't coupled, we have to * worry about the interaction between link.h version at compile time, * and ld-elf.so version at runtime...
I've submitted a patch that seems to get it working: https://source.winehq.org/patches/data/195960
It should allow a Wine binary to work correctly on all FreeBSD 12.x versions, whether they have that ld-elf patch or not, and regardless of the link.h header used at compile-time. All 4 combinations of old/new header vs library are handled correctly.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #14 from Alex S iwtcex@gmail.com --- (In reply to Damjan Jovanovic from comment #13)
Huh? This doesn't make any sense. You don't need to preserve compatibility in all directions.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #15 from Alex S iwtcex@gmail.com --- (In reply to Alex S from comment #14)
And, to be clear, there is no ABI breakage (with the exception of struct link_map size).
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #16 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Alex S from comment #14)
(In reply to Damjan Jovanovic from comment #13)
Huh? This doesn't make any sense. You don't need to preserve compatibility in all directions.
Yes you do. Compile on 12.1, run on 12.1: it uses offset 0 meaning l_addr, no _rtld_version_laddr_offset so it recalculates the address, all good. Now upgrade to 12.2, it crashes because _rtld_version_laddr_offset is there so assumes l_addr is already valid, and it is, but it is located at a different offset - what is at offset 0 is no longer l_addr -> crash. It would need to be recompiled on 12.2 to find l_addr at its new offset and use it correctly.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #17 from Alex S iwtcex@gmail.com --- (In reply to Damjan Jovanovic from comment #16)
(In reply to Alex S from comment #14)
(In reply to Damjan Jovanovic from comment #13)
Huh? This doesn't make any sense. You don't need to preserve compatibility in all directions.
Yes you do. Compile on 12.1, run on 12.1: it uses offset 0 meaning l_addr, no _rtld_version_laddr_offset so it recalculates the address, all good. Now upgrade to 12.2, it crashes because _rtld_version_laddr_offset is there so assumes l_addr is already valid, and it is, but it is located at a different offset - what is at offset 0 is no longer l_addr -> crash. It would need to be recompiled on 12.2 to find l_addr at its new offset and use it correctly.
I'm well aware of this, see comments #11 and #12.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #18 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Alex S from comment #17)
(In reply to Damjan Jovanovic from comment #16)
(In reply to Alex S from comment #14)
(In reply to Damjan Jovanovic from comment #13)
Huh? This doesn't make any sense. You don't need to preserve compatibility in all directions.
Yes you do. Compile on 12.1, run on 12.1: it uses offset 0 meaning l_addr, no _rtld_version_laddr_offset so it recalculates the address, all good. Now upgrade to 12.2, it crashes because _rtld_version_laddr_offset is there so assumes l_addr is already valid, and it is, but it is located at a different offset - what is at offset 0 is no longer l_addr -> crash. It would need to be recompiled on 12.2 to find l_addr at its new offset and use it correctly.
I'm well aware of this, see comments #11 and #12.
Your patch for this is a lot simpler than mine lol - 1 line of code ;-) - but it will break if you build a binary package on 12.2 and users run it on 12.1.
I have some comments on your Proton patches, I'll post them on the FreeBSD Bugzilla.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #19 from Alex S iwtcex@gmail.com --- (In reply to Damjan Jovanovic from comment #18)
Your patch for this is a lot simpler than mine lol - 1 line of code ;-) - but it will break if you build a binary package on 12.2 and users run it on 12.1.
That's the type of compatibility the packages aren't expected to provide. The server building FreeBSD 12 packages won't be upgraded to 12.2 until 12.1 EOL for precisely this reason.
https://bugs.winehq.org/show_bug.cgi?id=49437
--- Comment #20 from Alex S iwtcex@gmail.com --- (In reply to Alex S from comment #19)
the packages
s/the/official FreeBSD/
https://bugs.winehq.org/show_bug.cgi?id=49437
Alexander Vereeken Alexander88207@Protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Alexander88207@Protonmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=49437
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Fixed by SHA1| |6d829f2baf156738326acc77548 | |b37c90024a93c Status|NEW |RESOLVED Resolution|--- |FIXED Regression SHA1| |f728a5f3f9a4f1cad64aa3a1d3e | |9951940b0955c
--- Comment #21 from Damjan Jovanovic damjan.jov@gmail.com --- Patch committed, resolving fixed. Thank you!
https://bugs.winehq.org/show_bug.cgi?id=49437
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.0-rc1.
-
WineHQ Bugzilla