https://sourceware.org/bugzilla/show_bug.cgi?id=25993
Bug ID: 25993 Summary: Bug in bfd causes crashes with DXVK Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: wgpierce17 at gmail dot com Target Milestone: --- Created attachment 12539 --> https://sourceware.org/bugzilla/attachment.cgi?id=12539&action=edit Logs from running valgrind on ld during DXVK compilation I bisected a bug in DXVK to be created and fixed by two commits to bfd. DXVK transforms DX9-11 into Vulkan calls and is compiled as a .dll to be used with WINE. This is DXVK's homepage: https://github.com/doitsujin/dxvk DXVK uses mingw-w64-binutils to compile into a .dll The mingw-w64-binutils I tested with originates from here: https://aur.archlinux.org/packages/mingw-w64-binutils That gets built using a PKGBUILD script from the ArchLinux AUR: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mingw-w64-binutils The build process from that boils down to _targets="i686-w64-mingw32 x86_64-w64-mingw32" for _target in $_targets; do msg "Building ${_target} cross binutils" mkdir -p "$srcdir"/binutils-${_target} && cd "${srcdir}/binutils-${_target}" "$srcdir"/binutils-gdb/configure --prefix=/usr \ --target=${_target} \ --infodir=/usr/share/info/${_target} \ --enable-lto --enable-plugins \ --enable-deterministic-archives \ --disable-multilib --disable-nls \ --disable-werror make I bisected the bug with binutils in the DXVK issue here: https://github.com/doitsujin/dxvk/issues/1625 The bug manifests as WINE encountering a page fault at address 0x0, or executing illegal instructions, or a few other manifestations with different symptoms when DXVK is compiled with mingw-w64-binutils 2.34. mingw-w64-binutils 2.33 does not have this bug. We think the issue is that the linker makes DXVK jump to a bogus address and start executing garbage. I bisected the bug to be introduced by binutils commit ea933f17c3c6b9fa1daf8d03baa34f7bec855d6c: "Release bfd_alloc memory in bfd_check_format_matches" between the branch points for 2.33 and 2.34 I bisected the bug to be fixed in at least one case by binutils commit b03202e32c8235997b3485b0b4655926ad97a1cc: "bfd_get_size cache" between 2.34 branch point and master. Note that also in this bisection between 2.34 and master, there was a point where the reproduction hung with this in the WINE log instead of crashing outright: 49801.150:00c0:00c4:warn:seh:setup_exception_record exception outside of stack limits in thread 00c4 eip 00314be2 esp c79140f7 stack 0x222000-0x320000 49801.150:00c0:00c4:err:seh:setup_exception_record nested exception on signal stack in thread 00c4 eip 7bce9d9d esp 7ffdb930 stack 0x222000-0x320000 While these commits do both touch bfd, they don't touch the same file. Maybe the bug is only perturbed by the newer commit (or maybe my bisect is slightly off). Also, the newer commit isn't trying to address the bug caused by the original commit, so maybe the bug could be reintroduced anytime. I was asked to run valgrind on ld to see if there are any memory errors. I did this on both commit ea933f17c3c6b9fa1daf8d03baa34f7bec855d6c that introduced the problem and the commit right before it to see if there's any difference. I ran it while compiling dxvk by replacing the ld binary with a shell script that does this: exec valgrind -s --log-file=/path/to/logs/ld-%p.log /usr/bin/i686-w64-mingw32-ld.bfd.bak "$@" where /usr/bin/i686-w64-mingw32-ld.bfd.bak is the real ld that would be used. Both seem to report I believe the same number of use-after-free errors, so I think the bug got perturbed in different ways by these two commits to effectively introduce and get rid of the error. I've attached these logs for the build for the two commits. In particular, I observed the repro happen in the 32 bit d3d9.dll build, but both valgrinds outputs are the same. In the attached logs, they are logs-f24bdec48621f419fdc9dcd58f46891f062b7bc0/ld-102345.log logs-ea933f17c3c6b9fa1daf8d03baa34f7bec855d6c/ld-183630.log -- You are receiving this mail because: You are on the CC list for the bug.