From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29777 invoked by alias); 5 Jan 2007 00:53:50 -0000 Received: (qmail 29656 invoked by uid 22791); 5 Jan 2007 00:53:48 -0000 X-Spam-Check-By: sourceware.org Received: from theory.danglingpointers.net (HELO mail.danglingpointers.net) (69.77.167.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Jan 2007 00:53:42 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.danglingpointers.net (Postfix) with ESMTP id D8A0F3005D1 for ; Fri, 5 Jan 2007 08:35:03 +0000 (UTC) Date: Fri, 05 Jan 2007 00:53:00 -0000 From: jf To: gdb@sourceware.org Subject: signals in a multithreaded application Message-ID: X-GPG-FINGERPRINT: 6EB9 1EDB 07ED 2CBE AFCA BC3F E0EC C555 22C2 48B2 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00085.txt.bz2 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 ():
*** 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