On 2017.08.29 at 12:53 +0200, Martin Liška wrote: > On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote: > > On 2017.08.29 at 12:42 +0200, Martin Liška wrote: > >> On 08/29/2017 12:39 PM, Martin Liška wrote: > >>> (gdb) bt > >>> #0 0x00003fff950e58e4 in syscall () from /lib64/libc.so.6 > >>> #1 0x00003fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire > >>> (g=0x3fff94f26d40 <guard variable for (anonymous > >>> namespace)::__future_category_instance()::__fec>) at > >>> ../../../../libstdc++-v3/libsupc++/guard.cc:302 > >>> #2 0x00003fff94dfaf80 in __future_category_instance () at > >>> ../../../../../libstdc++-v3/src/c++11/future.cc:65 > >>> #3 std::future_category () at > >>> ../../../../../libstdc++-v3/src/c++11/future.cc:79 > >>> #4 0x00003fff94da98e8 in __static_initialization_and_destruction_0 > >>> (__priority=65535, __initialize_p=1) at > >>> ../../../../libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:50 > >>> #5 _GLOBAL__sub_I_compatibility_thread_c__0x.cc(void) () at > >>> ../../../../libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:200 > >>> #6 0x00003fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2 > >>> #7 0x00003fff960f19cc in _dl_start_user () from /lib64/ld64.so.2 > >> > >> strace says about it: > >> > >> futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource > >> temporarily unavailable) > > > > To me the whole issue looks related to PR81931. > > Are you using a clean build directory? Make sure you have the r251328 > > fix.> > > Yep. Directory was cleaner. I don't have the revision. Let me re-test it. > How can it be related to the PR as msgfmt is taken from system?
It may load a broken libstdc++.so.6 that was build without the fix. -- Markus
