* 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®