https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #10 from Joshua Kinard <kumba at gentoo dot org> ---
I rebuilt both glibc-2.19 and gcc-4.8.3 w/ debugging, though gcc's build system
managed to strip out or optimize away some of the debugging code. That said,
it's enough to see that the hang is being triggered by gcc because it makes two
futex syscalls in gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290:
syscall (SYS_futex, gi, _GLIBCXX_FUTEX_WAIT, expected, 0);
The first one lines up with the strace output where it gets -1 EAGAIN, and then
the second attempt is where the program hangs.
>From GDB:
(gdb) r
Starting program: /usr/obj/mips-unknown-linux-gnu/c2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Catchpoint 1 (call to syscall 4238), __pthread_initialize_minimal_internal ()
at nptl-init.c:328
(gdb) c
Continuing.
Catchpoint 1 (call to syscall 4238), 0x77f9dd90 in
__pthread_initialize_minimal_internal () at nptl-init.c:348
(gdb) break *0x77d2b684
Breakpoint 2 at 0x77d2b684: file ../sysdeps/unix/syscall.S, line 27.
(gdb) break *0x77ec621c
Breakpoint 3 at 0x77ec621c: file
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc,
line 290.
(gdb) c
Continuing.
Breakpoint 3, 0x77ec621c in __cxxabiv1::__cxa_guard_acquire (g=0x77f95500
<guard variable for (anonymous
namespace)::__future_category_instance()::__fec>)
at
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290
(gdb) c
Continuing.
Breakpoint 2, 0x77d2b684 in syscall () at ../sysdeps/unix/syscall.S:27
(gdb) c
Continuing.
Breakpoint 3, 0x77ec621c in __cxxabiv1::__cxa_guard_acquire (g=0x77f95500
<guard variable for (anonymous
namespace)::__future_category_instance()::__fec>)
at
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290
(gdb) c
Continuing.
<HANGS HERE>
^C
Program received signal SIGINT, Interrupt.
0x77d2b684 in syscall () at ../sysdeps/unix/syscall.S:27
(gdb)
