From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32016 invoked by alias); 24 Jun 2005 18:29:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31981 invoked by uid 22791); 24 Jun 2005 18:29:19 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 24 Jun 2005 18:29:19 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1DlsvV-0007ww-5Y for gdb@sources.redhat.com; Fri, 24 Jun 2005 14:29:17 -0400 Date: Fri, 24 Jun 2005 18:29:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: aborted thread backtrace stops at sighandler call Message-ID: <20050624182917.GA30147@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20050624151129.GH66895@keyslapper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050624151129.GH66895@keyslapper.net> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00239.txt.bz2 On Fri, Jun 24, 2005 at 11:11:29AM -0400, Louis LeBlanc wrote: > Well, often these were bus errors and gdb just couldn't nail things > down for me. Finally, I decided to catch these signals (SIGBUS, > SIGSEGV) and collect what info I could before calling abort() - which > preserves the stack pretty well according to pstack. When a problem > arises, I can look at the pstack output and see quite clearly that the > problem is this screwy network glitch I've never been able to track > down. Problem is when it's something else, gdb doesn't seem to be > able to see the preserved stack. > > Anyone have any idea how to get this? > > This is the backtrace for the aborted thread: > (gdb) bt > #0 0xfea1f82c in __tbl_2_huge_digits () from /usr/lib/libc.so.1 > #1 0xfe9d0a24 in sysconf () from /usr/lib/libc.so.1 > #2 0xfe9b6ce0 in ascftime () from /usr/lib/libc.so.1 > #3 0x0003c72c in XPCSigCheck (Sig=11, Info=0xfe776ad0, Context=0xfe776818) at xpcsig.c:347 > #4 0xff365b14 in ?? () > #5 0xff365b18 in ?? () > Previous frame identical to this frame (corrupt stack?) What this amounts to is a bug in GDB's signal frame unwinder for Solaris; I'm afraid I can't offer you any more help than that, since I don't generally develop or test on Solaris. -- Daniel Jacobowitz CodeSourcery, LLC