Signal debugging/tracing

[Chase Douglas]

I'm debugging a uClibc pthreads issue that occurs during a stress test  
where many threads are looping many times forking off child processes  
that exec() other executables. Child processes are writing to a pipe  
that the parent threads are reading. After some iterations in the  
loops, the threads that are reading from the pipe using read() are  
getting EINTR. If you put the read in a loop so that an EINTR is  
ignored and you just try again, each subsequent read call returns  
immediately with EINTR again.

I'm assuming right now that the EINTR is due to a stray signal  
occurring somewhere, probably due to pthreads. Unfortunately, my  
debugging isn't showing that the process is signaling any other  
process or itself in a way that would cause an EINTR. All I see are  
SIGRTMIN signals getting raised. If it truly is an issue of signals  
being raised, what techniques can be used to determine what signals  
are being sent to the process and from where are the signals coming  
from?

Thanks,
Chase Douglas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/