From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28441 invoked by alias); 18 Apr 2005 13:57:31 -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 28082 invoked from network); 18 Apr 2005 13:57:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 18 Apr 2005 13:57:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DNWkb-0001S7-7z; Mon, 18 Apr 2005 09:57:21 -0400 Date: Mon, 18 Apr 2005 13:57:00 -0000 From: Daniel Jacobowitz To: Roland Schwingel Cc: gdb , Mark Kettenis Subject: Re: gdb stack trace problems Message-ID: <20050418135721.GA5332@nevyn.them.org> Mail-Followup-To: Roland Schwingel , gdb , Mark Kettenis References: <4263BA56.9080509@onevision.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4263BA56.9080509@onevision.de> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00114.txt.bz2 On Mon, Apr 18, 2005 at 03:47:02PM +0200, Roland Schwingel wrote: > Ok... Thought that would be already known in a broader space, as after > asking > google for gdb stack trace problems there had been some hits but none with a > good answer... Saying "stack trace problems" for GDB is like saying "my code doesn't compile" for GCC. It doesn't tell us very much about what has gone wrong; stack backtracing is a complex problem with lots of dependencies. > Program received signal SIGSEGV, Segmentation fault. > [Switching to thread 2316.0xf8c] > 0x0040131d in crashIfZero (num=2) at gdbtest.c:17 > 17 *data=911; > (gdb) thr 1 > [Switching to thread 1 (thread 2316.0xf10)]#0 0x7c91eb94 in > ntdll!LdrAccessResource () from ntdll.dll > (gdb) bt > #0 0x7c91eb94 in ntdll!LdrAccessResource () from ntdll.dll > #1 0x7c91d85c in ntdll!ZwDelayExecution () from ntdll.dll > #2 0x7c8023ed in SleepEx () from /vol/c/WINDOWS/system32/kernel32.dll > #3 0x00000000 in ?? () from OK, here's a concrete problem. GDB 6.x has a (usually) more reliable prologue analyzer for x86, compared to GDB 5.3. However, the old one got lucky with SleepEx and the new one doesn't. I'd ask you to post disassembly of the function except I'm not sure how wise that is with a Microsoft DLL... Mark, you did the work on the i386 prologue analyzer. Any chance you could take a look at this? -- Daniel Jacobowitz CodeSourcery, LLC