From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20473 invoked by alias); 16 Apr 2005 14:09:54 -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 20461 invoked from network); 16 Apr 2005 14:09:52 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 16 Apr 2005 14:09:52 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DMnza-00009I-IT; Sat, 16 Apr 2005 10:09:50 -0400 Date: Sat, 16 Apr 2005 14:09:00 -0000 From: Daniel Jacobowitz To: Roland Schwingel Cc: gdb Subject: Re: gdb stack trace problems Message-ID: <20050416140949.GA542@nevyn.them.org> Mail-Followup-To: Roland Schwingel , gdb References: <425FD85D.1060201@onevision.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425FD85D.1060201@onevision.de> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00109.txt.bz2 On Fri, Apr 15, 2005 at 05:06:05PM +0200, Roland Schwingel wrote: > Hi.... > > At present we are suffering from stack trace problems with recent > versions of gdb. > I desperately hope someone knows a reason for it and can help. > > But from the beginning: > We are using gdb on cygwin to debug mingw programs. GDB works well but > in recent > version (starting with 6.x) it cannot produce correct stack dumps > anymore when something > has crashed. Our applications are multithreaded. > > In the past we used 5.3 which worked much better in that case but had > other problems. > We switched a while ago to 6.2 and then to 6.2.1 and today I compiled > 6.3.50 from CVS. > And it is all the same... When I get a crash I just get corrupted stacks > telling nothing useful. > > Does anyone know what is the reason for this and how to fix it? Sorry, but you haven't given us any information to answer your question with. Test case? Compiler version? Example? -- Daniel Jacobowitz CodeSourcery, LLC