... and resumes if a thread is kicked with a signal. No core dump or stack trace available.
Has anyone ever seen this behavior before and been able to annotate to any known gcc/glibc bugs?
Seen it once on a RHEL 5.5 Westmere and once on a RHEL 6.5 Sandybridge. First time I did do pstack and it was inside the cxa_guard_acquire local static initialization generated guard, running pstack (=attaching/detaching gdb) resumed the thread that time.
This appeared to be a manifestation of the bug fixed by this commit. Version with the bug can (three threads required for minimum reproduction) unsubscribe all threads waiting for static initialization to complete from the “wakeup call”, so the thread which triggers the initialization does not wake others up when done.
FSM of cxa_guard_acquire has four possible states:
The first thread that hits the local static variable switches the machine to "initializing", subsequent threads hitting it before the initialization is completed are switching it to "initializing + waiting" and blocking on a futex. Upon the initialization is completed the initializing thread wakes up everyone blocked on the futex if the state was "initializing + waiting" at the end of the initialization. A bug can cause "initializing + waiting to be reset back to "initializing".