linux-kernel - Signal debugging/tracing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 16 Sep 2008 16:47:34 -0400
From:	Chase Douglas <chasedouglas.lists@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Signal debugging/tracing

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/