From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23810 invoked by alias); 19 Apr 2005 06:58:30 -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 23794 invoked from network); 19 Apr 2005 06:58:24 -0000 Received: from unknown (HELO andromeda.onevision.de) (212.77.172.62) by sourceware.org with SMTP; 19 Apr 2005 06:58:24 -0000 Received: from [192.168.5.120] (oppenheim.onevision.de [192.168.5.120]) by andromeda.onevision.de (8.13.1/8.12.9/ROSCH/DDB) with ESMTP id j3J6vq0J021769; Tue, 19 Apr 2005 08:57:52 +0200 Message-ID: <4264ABCC.2030906@onevision.de> Date: Tue, 19 Apr 2005 06:58:00 -0000 From: Roland Schwingel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Mark Kettenis CC: drow@false.org, gdb@sources.redhat.com Subject: Re: gdb stack trace problems Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00124.txt.bz2 Hi Mark, Daniel and list.... Mark Kettenis wrote on 18.04.2005 19:10:57: > Date: Mon, 18 Apr 2005 09:57:21 -0400 > From: Daniel Jacobowitz > > > 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? > > Sure if someone can provide me with the dissassembly in AT&T syntax > for that function, or even better some assembler code that exhibits > the problem. No promises though that I'll fix this. Last time I > looked at some windows disassembler it looked like it was hand > optimized in such a way that the entire function needed to be analyzed > to do something useful; something that doesn't quite fit in the way we > do things in GDB. Here is the disassembly of one function (func1) that cannot be shown correctly from within gdb 6.3.50 in att flavor: (gdb) disas func1 Dump of assembler code for function func1: 0x004013ca : push %ebp 0x004013cb : mov %esp,%ebp 0x004013cd : sub $0x8,%esp 0x004013d0 : movl $0x64,(%esp) 0x004013d7 : call 0x401830 0x004013dc : sub $0x4,%esp 0x004013df : mov 0x8(%ebp),%eax 0x004013e2 : mov %eax,(%esp) 0x004013e5 : call 0x4012eb 0x004013ea : mov 0x8(%ebp),%eax 0x004013ed : mov %eax,(%esp) 0x004013f0 : call 0x40139d 0x004013f5 : leave 0x004013f6 : ret End of assembler dump. I hope this is what you requested. I will aid in tracking this down, wherever I can. As you see from the assembly Sleep() is called not SleepEx() as shown in the gdb 6.3.50 stack trace. In gdb 5.3 stack trace Sleep() is correctly shown if you look at my posting from yesterday Roland