This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
signals in a multithreaded application
- From: jf <jf at danglingpointers dot net>
- To: gdb at sourceware dot org
- Date: Fri, 5 Jan 2007 08:35:03 +0000 (UTC)
- Subject: signals in a multithreaded application
Hi,
I've got a weird issue that I am not sure if it is occurring because of GDB
or if it's an issue in glibc or otherwise. Basically, I'm in the process
of working on a bug that causes heap corruption via a double free(), which
(typically) causes a message along the lines of:
*** glibc detected *** double free or corruption (<type>): <address> ***
Followed by a call to abort() which raises SIGABRT. However I am finding
while debugging that sometimes the signal is never raised and I end up
with something more along the lines of:
*** glibc detected *** [Switching to Thread ...]
And the program continues running fine (minus of course the heap
corruption). Has anyone encountered this before? I changed the settings in
GDB telling it to not pass the exception to the application thinking that
the terminal was just messing up or similar and it just happened at the
same time GDB decided to switch threads (is that GDB changing threads or
the OS??), but I found that the signal is never delivered.
The thread appears to be in the __libc_message() function, and my thinking
is that perhaps its getting interrupted and then for whatever reason the
thread is never handed control again?
At any rate, I was curious if this is a known issue or someone else has
encountered it and save me the time of having to dig into the source code
for a bunch of unrelated programs.
Thanks.
--
Success is not final, failure is not fatal:
it is the courage to continue that counts.
-- Sir Winston Churchill