https://bugs.winehq.org/show_bug.cgi?id=49139
Bug ID: 49139 Summary: Wine crashes on startup on FreeBSD >= 5.7 Product: Wine Version: 5.7 Hardware: x86 OS: FreeBSD Status: NEW Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: damjan.jov@gmail.com
On FreeBSD, 32 bit Wine has started crashing on startup recently. I thought it was bug 49011, but even 5.8 still crashes. The output is simply:
002c:err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf6012920 0024:err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf6012920
A Git bisect revealed this regression:
commit 1ccd638b1aa85fb3c43b49d69d279cd509ebdc21 Author: Alexandre Julliard julliard@winehq.org Date: Tue Apr 21 11:27:53 2020 +0200
winegcc: No longer use a constructor for module initialization.
Signed-off-by: Alexandre Julliard julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=49139
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org Keywords| |regression, source Summary|Wine crashes on startup on |Regression: Wine crashes on |FreeBSD >= 5.7 |startup on FreeBSD >= 5.7 Regression SHA1| |1ccd638b1aa85fb3c43b49d69d2 | |79cd509ebdc21
https://bugs.winehq.org/show_bug.cgi?id=49139
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
https://bugs.winehq.org/show_bug.cgi?id=49139
konbu_sc@yahoo.co.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |konbu_sc@yahoo.co.jp
--- Comment #1 from konbu_sc@yahoo.co.jp --- Created attachment 67162 --> https://bugs.winehq.org/attachment.cgi?id=67162 dyn->d_un.d_ptr is already summed base address
002c:err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf6012920
Is this FreeBSD specific? The address is already summed base address. The dlls that has LLFLAGS like "-Wl,--image-base,0x7XXXXXXX" in Makefile.in causes the error.
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #2 from konbu_sc@yahoo.co.jp --- 0xf6012920 = 0x7b000000 + (0x7b000000 + 0x12920)
https://bugs.winehq.org/show_bug.cgi?id=49139
Gen Otsuji otsugen0000@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #67162|dyn->d_un.d_ptr is already |[patch for description|summed base address |FreeBSD]dyn->d_un.d_ptr is | |already summed by base | |address
--- Comment #3 from Gen Otsuji otsugen0000@gmail.com --- Comment on attachment 67162 --> https://bugs.winehq.org/attachment.cgi?id=67162 [patch for FreeBSD]dyn->d_un.d_ptr is already summed by base address
--- dlls/ntdll/loader.c.orig 2020-04-24 20:09:10.000000000 +0000 +++ dlls/ntdll/loader.c 2020-05-10 20:20:28.755105000 +0000 @@ -1344,7 +1344,21 @@ { case 0x60009990: init_array = (void *)((char *)map->l_addr + dyn->d_un.d_val); break; case 0x60009991: init_arraysz = dyn->d_un.d_val; break;
case 0x60009992: init_func = (void *)((char *)map->l_addr + dyn->d_un.d_val); break;
case 0x60009992:{char * addr1 = (char *)map->l_addr;char * addr2 = (char *)dyn->d_un.d_ptr;// assumptionif(addr1 < addr2){//FIXME("file:%s : base:%p < addr:%p\n", debugstr_w(wm->ldr.BaseDllName.Buffer), addr1, addr2);//FIXME("file:%s : base:%p < addr:%p\n", map->l_name, addr1, addr2);init_func = (void *)((char *)dyn->d_un.d_ptr);}elseinit_func = (void *)((char *)map->l_addr + dyn->d_un.d_val);break;} }
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #4 from Gen Otsuji otsugen0000@gmail.com --- Oh, sorry for newbe to this bug system. I don't know how to delete above comment with patch. anyway, This patch goes well with wine-5.8 ( with staging ) on amd64 FreeBSD 12.1 RELEASE-p5, I tested. And this patch is a quick hack, I'm satisfied, and don't want to go any further to the internal of wine.
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #5 from Damjan Jovanovic damjan.jov@gmail.com --- Gen, thank you so much for your debugging so far. It would have taken me forever to get started without it. I've begun my own debugging from the other end: how the bad value gets into the binary in the first place.
Your patch modifies dlls/ntdll/loader.c to use dyn->d_un.d_ptr as the initializer address instead of map->l_addr + dyn->d_un.d_val when its d_tag is 0x60009992. The d_tag of 0x60009992 comes from winebuild, function fixup_elf32(), called from fixup_constructors(), called from main() when "--fixup-ctors" was passed as a command line option. winebuild gets passed --fixup-ctors from winegcc when its own function fixup_constuctors() is called, and the commit I bisected the regression to (1ccd638b1aa85fb3c43b49d69d279cd509ebdc21) calls fixup_constructors() in a new place.
However what does 0x60009992 actually do? The fixup_elf32() function in winebuild iterates over (what are effectively) Elf32_Dyn entries in the PT_DYNAMIC section, and overwrites the d_tag containing DT_INIT with 0x60009992. Presumably, this is done so ELF initializers aren't run in the native dynamic loader, but in Wine's NTDLL. But the 0x60009992 is still in every other way a DT_INIT entry.
Testing on native FreeBSD binaries on both i386 and amd64 shows how (1) the DT_INIT value in my own test executable on disk matches the value returned by dlinfo() in memory, and (2) the value is also given by "objdump -x <executable>|grep INIT".
But is that value an absolute address, or an offset relative to l_addr? Both Wine and glibc seem to treat it as the latter: https://code.woboq.org/userspace/glibc/elf/dl-init.c.html#58 DL_CALL_DT_INIT(l, l->l_addr + l->l_info[DT_INIT]->d_un.d_ptr, argc, argv, env);
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #6 from Damjan Jovanovic damjan.jov@gmail.com --- dlinfo() is implemented in FreeBSD's run-time dynamic linker, rtld-elf.
/usr/src/libexec/rtld-elf/rtld.h:
/* These items are computed by map_object() or by digest_phdr(). */ caddr_t mapbase; /* Base address of mapped region */ size_t mapsize; /* Size of mapped region in bytes */ size_t textsize; /* Size of text segment in bytes */ Elf_Addr vaddrbase; /* Base address in shared object file */ caddr_t relocbase; /* Relocation constant = mapbase - vaddrbase */
/usr/src/libexec/rtld-elf/rtld.c, function linkmap_add():
obj->linkmap.l_addr = obj->mapbase;
obj->linkmap.l_ld = obj->dynamic; #ifdef __mips__ /* GDB needs load offset on MIPS to use the symbols */ obj->linkmap.l_offs = obj->relocbase; #endif
/usr/src/libexec/rtld-elf/rtld.c, function digest_dynamic1():
case DT_INIT: obj->init = (Elf_Addr)(obj->relocbase + dynp->d_un.d_ptr); break;
So what is returned in link_map.l_addr is obj->mapbase, even though when the dynamic linker calls initializers by itself it uses obj->relocbase instead as the offset.
As per the comments, and as confirmed by map_object() in map_object.c: obj->relocbase = mapbase – base_vaddr;
we have, through maths: relocbase = mapbase – vaddrbase mapbase = relocbase + vaddrbase
Thus the value being returned to Wine via dlinfo() has l_addr = mapbase = relocbase + vaddrbase, whereas internally the dynamic linker only uses relocbase. Thus the value being given to Wine is already too high by vaddrbase bytes, even before adding dyn->d_un.d_val.
How does Wine not crash on Linux? On http://man7.org/linux/man-pages/man3/dlinfo.3.html the description for l_addr in GNU's dlinfo() is:
ElfW(Addr) l_addr; /* Difference between the address in the ELF file and the address in memory */
ie. GNU's l_addr is FreeBSD's l_offs – and only available on MIPS.
Thus the bug could be fixed in 2 ways: 1. Wine could use link_map.l_offs instead of link_map.l_addr, but that would only work on MIPS until FreeBSD's rtld-elf is patched to support other platforms. 2. FreeBSD's rtld-elf could be changed to return obj->relocbase in link_map.l_addr instead of obj->mapbase.
What is the right approach?
On http://man7.org/linux/man-pages/man3/dlinfo.3.html it states: “This function is a nonstandard GNU extension,” and adds “This function derives from the Solaris function of the same name and also appears on some other systems. The sets of requests supported by the various implementations overlaps only partially.”
NetBSD does what GNU does, returning relocbase, so Wine should work there: https://github.com/NetBSD/src/blob/72845ff20a2fedf73f626b82df2f34a63bb17b77/... obj->linkmap.l_addr = obj->relocbase; which was my option 2 above, which they implemented in 2002 (https://github.com/NetBSD/src/commit/d1351c627c5f4d5ac41a3f680243d57293e0ce1...).
OpenBSD doesn't even seem to have dlinfo().
Solaris's man page sounds the same as FreeBSD's (https://docs.oracle.com/cd/E36784_01/html/E36874/dlinfo-3c.html), and I haven't been able to find the source for OpenIndiana's dynamic linker yet to prove otherwise.
Couldn't find anything about MacOS's dlinfo() either, but I assume it works as per ccce5f769dbbab92b2fa872c27f1d36343a77afe.
Thus this regression seems to break many operating systems; only Linux, Mac and NetBSD work for sure. If Wine plans to remain portable, it might also consider option 3: implement its own portable ELF loader, and use in place of the native one whose dlinfo() implementation (if any) doesn't always allow us to calculate correct initializer addresses.
As it stands now, Wine > 5.6 is permanently unusable on FreeBSD and other platforms that won't provide relocbase in dlinfo()'s l_addr. Gen's patch, which ignores l_addr, will only work when relocbase is 0, which only happens when the library is loaded at the address it wanted, ie. when it hasn't been relocated – and ELF libraries are relocatable, so crashes will still happen every now and then. Reverting the commit that caused this “regression” will get Wine running, but (AFAIK) only because initializers are running in the dynamic linker instead of NTDLL, which means things are getting initialized in the wrong order (ie. Windows code might run before Wine is initialized?), with unpredictable consequences.
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #7 from Damjan Jovanovic damjan.jov@gmail.com --- Patching FreeBSD's dynamic linker as per my earlier option 2 (just like how NetBSD did) gets Wine working again. Option 1 would alternatively be to remove the conditional "#ifdefs __mips__" around l_offs, here and in /usr/include/sys/link_elf.h, thus providing l_offs on all platforms, then patch Wine to use it.
If Wine is going to make GNU-compatible dlinfo() a requirement, then this should be RESOLVED NOTOURBUG and fixed upstream?
diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 2d15560fb908..647626e3a41d 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -3951,7 +3951,7 @@ linkmap_add(Obj_Entry *obj) struct link_map *prev;
obj->linkmap.l_name = obj->path; - obj->linkmap.l_addr = obj->mapbase; + obj->linkmap.l_addr = obj->relocbase; obj->linkmap.l_ld = obj->dynamic; #ifdef __mips__ /* GDB needs load offset on MIPS to use the symbols */
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #8 from Gen Otsuji otsugen0000@gmail.com --- (In reply to Damjan Jovanovic from comment #7) Hi Damjan, it's great work, and very difficult for me. my question is in Makefile.in how the option of "-Wl,--image-base,0x7bc00000" works? The dlls without this option, not summed. The dlls with this option, already summed. I'm wondering this difference.
https://bugs.winehq.org/show_bug.cgi?id=49139
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll
--- Comment #9 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Gen Otsuji from comment #8)
(In reply to Damjan Jovanovic from comment #7) Hi Damjan, it's great work, and very difficult for me. my question is in Makefile.in how the option of "-Wl,--image-base,0x7bc00000" works? The dlls without this option, not summed. The dlls with this option, already summed. I'm wondering this difference.
I finally found a way to fix this purely within Wine, without changes to FreeBSD's rtld-elf. Patch sent: https://source.winehq.org/patches/data/185377
Let me explain it with a worked example.
A binary won't know which memory address it will be loaded at. So it generates pointers to addresses from some offset it would prefer, and if it gets loaded at a different address, the offset between its preferred offset and the one it actually got can be added to these pointers to go to the right place.
So the binary might prefer starting address 20000, and there's a pointer eg. from DT_INIT pointing to 20150. But it gets loaded at address 30000, which is 10000 bytes above what it preferred. So we can add 20150 + 10000 = 30150.
On Linux and NetBSD, l_addr == 10000, the difference from what it wanted to what it got. On FreeBSD, l_addr == 30000, the absolute address where it actually got loaded.
Now what "l_addr + d_un.d_ptr" does on FreeBSD, is add 30000 + 20150 = 50150, which is always wrong. We have to add the relocation offset to d_un.d_ptr, not the absolute addresses where the binary was loaded.
-Wl,--image-base,0x7bc00000 just tells the linker to use that as the preferred address instead of some default, probably because some applications expect DLLs at certain addresses. It doesn't really matter in this discussion.
https://bugs.winehq.org/show_bug.cgi?id=49139
Alex S iwtcex@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iwtcex@gmail.com
--- Comment #10 from Alex S iwtcex@gmail.com --- (In reply to Damjan Jovanovic from comment #6)
ie. GNU's l_addr is FreeBSD's l_offs
That sounds like a positively nasty footgun. I wonder what else is broken (besides Wine).
Solaris's man page sounds the same as FreeBSD's (https://docs.oracle.com/cd/E36784_01/html/E36874/dlinfo-3c.html), and I haven't been able to find the source for OpenIndiana's dynamic linker yet to prove otherwise.
I believe the code somewhere around https://github.com/illumos/illumos-gate/blob/67d74cc3e7c9d9461311136a0b20698... (the ADDR macro is defined at https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8b...). I'm a bit lost in it, to be honest.
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #11 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Alex S from comment #10)
(In reply to Damjan Jovanovic from comment #6)
ie. GNU's l_addr is FreeBSD's l_offs
That sounds like a positively nasty footgun. I wonder what else is broken (besides Wine).
Solaris's man page sounds the same as FreeBSD's (https://docs.oracle.com/cd/E36784_01/html/E36874/dlinfo-3c.html), and I haven't been able to find the source for OpenIndiana's dynamic linker yet to prove otherwise.
I believe the code somewhere around https://github.com/illumos/illumos-gate/blob/ 67d74cc3e7c9d9461311136a0b2069813a3fd927/usr/src/cmd/sgs/rtld/common/elf. c#L1733 (the ADDR macro is defined at https://github.com/illumos/illumos-gate/blob/ 4e0c5eff9af325c80994e9527b7cb8b3a1ffd1d4/usr/src/cmd/sgs/include/rtld. h#L889). I'm a bit lost in it, to be honest.
DT_INIT has to add the "relocbase" offset to the pointer, so whatever it is adding, is the relocbase:
---snip--- case DT_INIT: if (dyn->d_un.d_ptr != 0) INIT(lmp) = (void (*)())(dyn->d_un.d_ptr + base); break; ---snip---
ie. here, "base" = relocbase. Where did "base" come from?
---snip--- if (ehdr->e_type == ET_EXEC) base = 0; else base = addr; ---snip---
And what is written into l_addr?
---snip--- ADDR(lmp) = addr; ---snip---
where:
---snip--- #define ADDR(X) ((X)->rt_public.l_addr) ---snip---
So if I am reading that correctly, OpenIndiana returns the relocbase in link_map.l_addr like GNU and NetBSD.
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #12 from Alex S iwtcex@gmail.com --- (In reply to Damjan Jovanovic from comment #11)
So if I am reading that correctly, OpenIndiana returns the relocbase in link_map.l_addr like GNU and NetBSD.
This is probably worth bringing to the FreeBSD bug tracker or some mailing list.
(In reply to Damjan Jovanovic from comment #9)
Now what "l_addr + d_un.d_ptr" does on FreeBSD, is add 30000 + 20150 = 50150, which is always wrong.
I actually have some code doing exactly that.
Looking at https://github.com/freebsd/freebsd/blob/d4300f6714811c0a28c0a701ae28952e5758...:
Obj_Entry * map_object(int fd, const char *path, const struct stat *sb) { ... base_vaddr = trunc_page(segs[0]->p_vaddr); ... base_addr = (caddr_t) base_vaddr; ... mapbase = mmap(base_addr, mapsize, PROT_NONE, base_flags, -1, 0); ... if (base_addr != NULL && mapbase != base_addr) { _rtld_error("%s: mmap returned wrong address: wanted %p, got %p", path, base_addr, mapbase); goto error1; } ... obj->mapbase = mapbase; obj->mapsize = mapsize obj->vaddrbase = base_vaddr; obj->relocbase = mapbase - base_vaddr; ... }
Thus, if p_vaddr == 0 --> mapbase == relocbase otherwise if p_vaddr != 0 --> relocbase == 0. Default vaddr value seems to be 0 with gcc (and 0x40 with clang). Well, at least that explains why I didn't bump into this issue.
https://bugs.winehq.org/show_bug.cgi?id=49139
--- Comment #13 from Alex S iwtcex@gmail.com --- (In reply to Alex S from comment #12)
and 0x40 with clang
Meh. It's also 0 because I didn't notice PHDR being placed before LOAD in readelf output.
https://bugs.winehq.org/show_bug.cgi?id=49139
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |0fd3f0266e05f6afa710fa2b5a2 | |54b0ed88bac0f Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #14 from Damjan Jovanovic damjan.jov@gmail.com --- My patch to Wine that works out relocbase from mapbase on FreeBSD has been committed. I'll bring this to FreeBSD's attention too.
Resolving fixed. A big thank you to everyone involved.
https://bugs.winehq.org/show_bug.cgi?id=49139
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.9.
-
WineHQ Bugzilla