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-0x32
49801.150:00c0:00c4:err:seh:setup_exception_record nested exception on signal
stack in thread 00c4 eip 7bce9d9d esp 7ffdb930 stack 0x222000-0x32
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.
