This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]