This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
$ 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:

-plugin C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/liblto_plugin-0.dll
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-m i386pe -Bdynamic -o ./lzmadec.exe
C:\\msys32\\tmp\\ccQKP1WD.o -lmingw32 -lgcc -lgcc_eh -lmoldname
-lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32
-lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt

The backtrace of crashing is as below:

=>0 0xb74d78e3 in (+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
  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
  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)
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== 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
==22314==    by 0x441C21: bfd_set_section_contents at
==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
==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.

Qian Hong


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]