mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Signal debugging/tracing
@ 2008-09-16 20:47 Chase Douglas
  0 siblings, 0 replies; only message in thread
From: Chase Douglas @ 2008-09-16 20:47 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2008-09-16 20:47 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-16 20:47 Signal debugging/tracing Chase Douglas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®