https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #4 from Joshua Kinard <kumba at gentoo dot org> ---
It looks like the bug might be somewhere in __cxa_guard_acquire() in
libstdc++-v3/lubsupc++/guard.cc, as that references glibc and futexes. strace
indicates that the same syscall was invoked twice in a row -- could this be a
double-locking bug?
This is what I traced out in gdb:
¦0x77ed91cc <__cxa_guard_acquire+336> sw zero,32(sp)
B+>¦0x77ed91d0 <__cxa_guard_acquire+340> b 0x77ed9144
<__cxa_guard_acquire+200>
|
|->¦0x77ed9144 <__cxa_guard_acquire+200> lw t9,-28620(gp)
¦0x77ed9148 <__cxa_guard_acquire+204> li a0,4238
¦0x77ed914c <__cxa_guard_acquire+208> move a1,s0
¦0x77ed9150 <__cxa_guard_acquire+212> move a2,zero
¦0x77ed9154 <__cxa_guard_acquire+216> lw a3,32(sp)
¦0x77ed9158 <__cxa_guard_acquire+220> jalr t9
|
|->¦0x77d50850 <syscall> lui gp,0x9
¦0x77d50854 <syscall+4> addiu gp,gp,-2624
¦0x77d50858 <syscall+8> addu gp,gp,t9
¦0x77d5085c <syscall+12> li v0,4000
¦0x77d50860 <syscall+16> syscall
<HANGS HERE>
¦0x77d50864 <syscall+20> bnez a3,0x77d50840
¦0x77d50868 <syscall+24> nop
¦0x77d5086c <syscall+28> jr ra
¦0x77d50870 <syscall+32> nop
¦0x77d50874 <syscall+36> nop
¦0x77d50878 nop
¦0x77d5087c nop
I can see the first futex syscall (li a0,4238), and I think it looks like
inside that syscall, it's doing some loads and adds, then makes a "generic"
syscall (#4000), probably passing the computed 0x108e value as the first
argument, which would translate into another futex syscall, which jives with
what strace says. Is taking a futex inside of a futex a good thing? It's
obvious that something with the R1x000 CPU is coming into play as well, but I
don't know what exactly.
