MinGW ld from msys2 crashes on Wine when linking MinGW xz, valgrind reports "Invalid read of size 4"

[Qian Hong <fracting at gmail dot com>]

Dear list,


I'm working on improving Wine support for win32 version of GNU
toolchains. I use Wine + MSYS2 to build as many packages as possible.
With Wine Staging 1.7.52 and a few custom Wine hacks, I've already
successfully built 300+ MSYS2 packages and a few MinGW packages.
However, when building the MinGW xz packages, I recently found a
crashing in ld.exe

My msys2 version is:
fracting@fracting-ThinkPad-Edge-E431 MINGW32 ~
$ uname -a
MINGW32_NT-5.1  2.3.0(0.290/5/3) 2015-09-15 09:26 i686 Msys

ld version is:
$ ld --version
GNU ld (GNU Binutils) 2.25.1 (install from official MSYS2 binary package)

The command line to build the MinGW xz package is:
$ git clone https://github.com/Alexpux/MINGW-packages
$ cd mingw-w64-xz
$ makepkg-mingw -f -s --skippgpcheck --noconfirm

The crashing happens when linking lzmadec.exe, which is part of the xz
package. The command line is like below:

C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/bin/ld.exe
-plugin C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/liblto_plugin-0.dll
-plugin-opt=C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\\msys32\\tmp\\ccsbYSYT.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh
-plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh
-plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-m i386pe -Bdynamic -o ./lzmadec.exe
C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/crt2.o
C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/crtbegin.o
-LC:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0
-LC:/msys32/mingw32/bin/../lib/gcc
-LC:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib
-LC:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../lib
-LC:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib
-LC:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../..
C:\\msys32\\tmp\\ccQKP1WD.o -lmingw32 -lgcc -lgcc_eh -lmoldname
-lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32
-lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt
C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/default-manifest.o
C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/crtend.o

The backtrace of crashing is as below:

Backtrace:
=>0 0xb74d78e3 in libc.so.6 (+0x1328e3) (0x0122f928)
  1 0x7e468cbc MSVCRT__fwrite_nolock+0xdb(ptr=<couldn't compute
location>, size=<couldn't compute location>, nmemb=<couldn't compute
location>, file=<couldn't compute location>)
[/home/fracting/src/wine-patched/dlls/msvcrt/file.c:3900] in msvcrt
(0x0122f928)
  2 0x7e468bbe MSVCRT_fwrite+0x3d(ptr=<couldn't compute location>,
size=<couldn't compute location>, nmemb=<couldn't compute location>,
file=<couldn't compute location>)
[/home/fracting/src/wine-patched/dlls/msvcrt/file.c:3877] in msvcrt
(0x0122f978)
  3 0x0042d6c0 in ld (+0x2d6bf) (0x7e4e56e0)
  4 0x0042cc2f in ld (+0x2cc2e) (0x00251510)
  5 0x00456314 in ld (+0x56313) (0x00251510)
  6 0x00435f95 in ld (+0x35f94) (0x00000000)
  7 0x004503f3 in ld (+0x503f2) (0x00000001)
  8 0x00454b2d in ld (+0x54b2c) (0x00000000)
  9 0x00415363 in ld (+0x15362) (0x0122fd38)
  10 0x004de996 in ld (+0xde995) (0x0122fd38)
  11 0x004013e2 in ld (+0x13e1) (0x0122fe00)
  12 0x7b8685ac call_process_entry+0xb() in kernel32 (0x0122fe18)

Unfortunately I'm not able to provide symbols of ld.exe, because when
I test with my custom build of ld.exe with debugging symbols, the
crash disappeared.

I analysed the tracing log from Wine, and snip a piece of interesting log:

011b:Call msvcrt.malloc(00000848) ret=004a8428
011b:Call ntdll.RtlAllocateHeap(00240000,00000000,00000848) ret=7e4784b5
011b:Ret  ntdll.RtlAllocateHeap() retval=013df628 ret=7e4784b5
011b:Ret  msvcrt.malloc() retval=013df628 ret=004a8428
011b:Call msvcrt.memset(013df630,00000000,00000840) ret=00433c43
011b:Ret  msvcrt.memset() retval=013df630 ret=00433c43
011b:Call msvcrt.memcpy(013df6d0,013ded88,00000300) ret=00449343
011b:Ret  msvcrt.memcpy() retval=013df6d0 ret=00449343
011b:Call msvcrt.memcpy(013df9d0,013df190,0000048f) ret=00449343
011b:Ret  msvcrt.memcpy() retval=013df9d0 ret=00449343
011b:Call msvcrt.fsetpos(7e4f16e0,0122f988) ret=004ce7bd
011b:trace:msvcrt:_lock (35)
011b:trace:msvcrt:MSVCRT__lseeki64 :fd (7) handle (0x80)
011b:trace:msvcrt:MSVCRT__lseeki64 :fd (7) to c400 pos SEEK_SET
011b:Call KERNEL32.SetFilePointer(00000080,0000c400,0122f8b4,00000000)
ret=7e46df30
011b:Ret  KERNEL32.SetFilePointer() retval=0000c400 ret=7e46df30
011b:trace:msvcrt:_unlock (35)
011b:Ret  msvcrt.fsetpos() retval=00000000 ret=004ce7bd
011b:Call msvcrt.fwrite(013df630,00000001,00000a00,7e4f16e0) ret=0042d6c0
011b:trace:msvcrt:_lock (35)
011b:trace:seh:raise_exception code=c0000005 flags=0 addr=0xb74958e3
ip=b74958e3 tid=011b
011b:trace:seh:raise_exception  info[0]=00000000
011b:trace:seh:raise_exception  info[1]=013e0000
011b:trace:seh:raise_exception  eax=013e0000 ebx=b750c000 ecx=00000030
edx=00273af0 esi=00000800 edi=00003800
011b:trace:seh:raise_exception  ebp=0122f8e8 esp=0122f890 cs=0073
ds=007b es=007b fs=0033 gs=003b flags=00010202
011b:trace:seh:call_vectored_handlers calling handler at 0x64b44060
code=c0000005 flags=0
011b:trace:seh:call_vectored_handlers handler at 0x64b44060 returned 0
011b:trace:seh:call_stack_handlers calling handler at 0x7bcb34b1
code=c0000005 flags=0
011b:Call KERNEL32.UnhandledExceptionFilter(0122f374) ret=7bcb350f

In the above log, the malloc call with size 0x848 returned the pointer
0x013df628, later then a fwrite call try to read 0xa00 bytes from the
address 0x13df630 and write to the file stream 0x7e4f16e0, which cause
a crash.

Then I retest ld.exe with Wine + Valgrind , and found the below warnings:

==22314==
==22314== Invalid read of size 4
==22314==    at 0x402EA18: memcpy (vg_replace_strmem.c:1019)
==22314==    by 0x5340CBB: MSVCRT__fwrite_nolock (file.c:3900)
==22314==    by 0x5340BBD: MSVCRT_fwrite (file.c:3877)
==22314==    by 0x437235: cache_bwrite  at ../../binutils-2.25.1/bfd/cache.c:378
==22314==    by 0x4363D2: bfd_bwrite at ../../binutils-2.25.1/bfd/bfdio.c:211
==22314==    by 0x46DDF1: coff_set_section_contents at
../../binutils-2.25.1/bfd/coffcode.h:4487
==22314==    by 0x441C21: bfd_set_section_contents at
../../binutils-2.25.1/bfd/section.c:1492
==22314==    by 0x4627CF: rsrc_process_section at peigen.c:4295
==22314==    by 0x462E24: _bfd_pei_final_link_postscript at peigen.c:4516
==22314==    by 0x46499A: _bfd_coff_final_link at
../../binutils-2.25.1/bfd/cofflink.c:947
==22314==    by 0x41A130: ldwrite at ../../binutils-2.25.1/ld/ldwrite.c:581
==22314==    by 0x417560: main at ../../binutils-2.25.1/ld/ldmain.c:428

I'm not familiar with binutils source code, so I need some help, could
someone take a look and see if there is a ld bug here, or otherwise
help to point out what might be wrong in the Wine side?

Any comment is great appreciated, thanks for the great work.

-- 
Regards,
Qian Hong

-
http://www.winehq.org