RFH: Strange mingw behaviour

[Martin Koegler <martin dot koegler at chello dot at>]

I'm trying to debug a mingw crash. My program failed to start with a acess violation on Windows.

I was able to track it down to:
====
#include <tr1/unordered_map>

int main()
{
std::tr1::unordered_map<int,int> xxx;
return 0;
}
========

Cross-compiled for x86_64-w64-mingw32 with a unpatched binutils 2.26 (https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-binutils)
and gcc 5.3 (https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-gcc) the initialisation of unordered_map crashes.
[OS: OpenSuSE Leap 42.1 + the mingw runtime from https://build.opensuse.org/project/show/windows:mingw:win64].

x86_64-w64-mingw32-gcc -o t.exe t.cpp -gstabs /usr/x86_64-w64-mingw32/sys-root/mingw/lib/gcc/x86_64-w64-mingw32/5.3.0/libstdc++.dll.a

Using wine, I was able to generate a crash dump:
  0 0x00000000004036b4 _ZNK9__gnu_cxx5__ops14_Iter_less_valclIPKmKyEEbT_RT0_+0x14(this=0x32fa98, __it=0x100000200, __val=0x32fb18) [/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/c++/bits/predefined_ops.h:55] in t (0x000000000032fa20)
  1 0x0000000000403ecd in t (+0x3ecc) (0x000000000032fa70)
  2 0x0000000000403e39 in t (+0x3e38) (0x000000000032fb00)
  3 0x0000000000403733 _ZNKSt3tr18__detail20_Prime_rehash_policy11_M_next_bktEy+0x32(this=0x32fb18, __n=0) [/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/c++/tr1/hashtable_policy.h:424] in t (0x000000000032fb00)
  4 0x0000000000403be0 in t (+0x3bdf) (0x000000000032fb90)
  5 0x0000000000403d44 in t (+0x3d43) (0x000000000032fbb0)
  6 0x0000000000403cc9 in t (+0x3cc8) (0x000000000032fbf0)
  7 0x0000000000401607 main+0x46() [t.cpp:6] in t (0x000000000032fc80)
  8 0x00000000004013ed in t (+0x13ec) (0x0000000000441970)
  9 0x000000000040152b in t (+0x152a) (0x0000000000401510)

The import library was generated during GCC build by [https://build.opensuse.org/build/windows:mingw:win64/openSUSE_42.1/x86_64/mingw64-gcc]:
libtool: link:  x86_64-w64-mingw32-g++ -L/usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/mingw/lib -isystem /usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include -isystem /usr/x86_64-w64-mingw32/sys-root/mingw/mingw/include --sysroot=/usr/x86_64-w64-mingw32/sys-root   -shared -nostdlib /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/dllcrt2.o /usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/crtbegin.o  .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o  -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive  -L/usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/mingw/lib -L/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0 -L/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib -L/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt /usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/crtend.o  -Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver   -o .libs/libstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libstdc++.dll.a

The strange thing is, that directly linking with the dll directly produces a working program:

x86_64-w64-mingw32-gcc -o t.exe t.cpp -gstabs /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll 

Using the libstdc++-6.dll generated by gcc 5.2.0 + binutils 2.25 also works with the program linked against the current libstdc++.dll.a

I guess, that it is related to the __prime_list symbol:
=====================
d003942.o:
                 U _head_libstdc___6_dll
0000000000000000 i .idata$4
0000000000000000 i .idata$5
0000000000000000 i .idata$6
0000000000000000 i .idata$7
0000000000000000 I __imp__ZNSt8__detail12__prime_listE
0000000000000000 I __nm__ZNSt8__detail12__prime_listE
0000000000000000 t .text
=====================

as the following sample shows the same behaviour [broken if linked against the dll.a and works otherwise]:
======
#include <tr1/unordered_map>
#include <stdio.h>

using namespace std::tr1::__detail;

 enum { _S_n_primes = sizeof(unsigned long) != 8 ? 256 : 256 + 48 };

int main()
{
unsigned long __n = 10;
printf("%p %p %d %uld\n", __prime_list, __prime_list + _S_n_primes, _S_n_primes,__n);
    const unsigned long* __p = std::lower_bound(__prime_list, __prime_list
                                                + _S_n_primes, __n);
printf("%p\n", __p);
return 0;
}
======

The version linked against dll.a and runned with the 5.3 libstdc++ dll prints a value of 0000000100000000 for __prime_list before crashing.

Smallest sample:
=====
#include <tr1/unordered_map>
#include <stdio.h>

using namespace std::tr1::__detail;

int main()
{
printf("%p\n", __prime_list);
printf("%lu %lu\n", __prime_list[0], __prime_list[1]);
return 0;
}
=====

x86_64-w64-mingw32-gcc -o t2.exe t2.cpp -gstabs /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
=>
0000000000407b20
2036999679 2425356288

x86_64-w64-mingw32-gcc -o t2.exe t2.cpp -gstabs /usr/x86_64-w64-mingw32/sys-root/mingw/lib/gcc/x86_64-w64-mingw32/5.3.0/libstdc++.dll.a
=>
0000000100000000
and a access violation.

I'm not sure, what component I should blame for the relocation error - I'm in favour of binutils. Could somebody please be so kind to provide suggestions how to proceed.

Regards,
Martin