From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26624 invoked by alias); 4 Oct 2004 09:00:07 -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 26388 invoked from network); 4 Oct 2004 09:00:06 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 4 Oct 2004 09:00:06 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i94904AR027827 for ; Mon, 4 Oct 2004 11:00:05 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Mon, 04 Oct 2004 10:58:51 +0200 Message-Id: <5.2.0.9.1.20041004092344.01ced058@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Mon, 04 Oct 2004 13:12:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: Stack "signal handler called" In-Reply-To: <20041003184230.GB10453@nevyn.them.org> References: <5.2.0.9.1.20040930114255.01ce7bf0@NT_SERVER> <5.2.0.9.1.20040930114255.01ce7bf0@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-10/txt/msg00041.txt.bz2 >> I tried to examine a target where a thread had crashed. I issued bt >> and got only one frame, somewhere in memcpy.c. For the second >> frame gdb only printed . What does this mean? >> I found the string in stack.c but I couldn't make out the meaning. >> Does it mean that the call stack was destroyed? Some invalid >> addresses in the call stack? > >It means that GDB thinks that a signal handler has been invoked, and >that the frames above it are in the signal handler context. If that's >incorrect, you've found a bug in GDB. > >(You mentioned threads. It may be that the application is placing >thread stacks in such a way that GDB is confused...) There are some possibilities for errors on our side. The callstack could be made up wrong in case of a trap, and our debugger could also read and interpret wrong data. But it usually works fine. As it didn't work in this case I tried if gdb could perform better. As it didn't get further either I'll assume for now that there really was an error in the call stack. More investigations didn't reveal anything. Thanks bye Fabi