From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7273 invoked by alias); 8 May 2005 13:31:21 -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 7141 invoked by uid 22791); 8 May 2005 13:31:10 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 08 May 2005 13:31:10 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j48DUL03014914; Sun, 8 May 2005 15:30:21 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j48DUKFS002481; Sun, 8 May 2005 15:30:20 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j48DUKQc012365; Sun, 8 May 2005 15:30:20 +0200 (CEST) Date: Sun, 08 May 2005 13:31:00 -0000 Message-Id: <200505081330.j48DUKQc012365@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: roland.schwingel@onevision.de CC: gdb@sourceware.org, me@cgf.cx In-reply-to: <4275D0AC.8000205@onevision.de> (message from Roland Schwingel on Mon, 02 May 2005 09:03:08 +0200) Subject: Re: gdb stack trace problems (Addendum) References: <4275D0AC.8000205@onevision.de> X-SW-Source: 2005-05/txt/msg00096.txt.bz2 Date: Mon, 02 May 2005 09:03:08 +0200 From: Roland Schwingel Hi Mark... Have you already had some time to look into my results with your patch to the i386 stack unwinder? At basically it could work but obviously it is not advancing to the next stack frame... Attached you will find my results This isn't very encouraging. My approach obviously isn't working very well. My suggestion is to go for a Windows-specific solution, where one would use a special unwinder for the sort of undebuggable code that's found in the Windows system DLLs. But I'm afraid I can't really do much since I don't have a Windows system. Chris, is there any change you can hack something like this into i386-cygwin-tdep.c? Mark ----- Forwarded by Roland Schwingel/Onevision on 02.05.2005 08:59 ----- gdb-owner@sources.redhat.com wrote on 26.04.2005 11:16:03: > Hi... > > Mark Kettenis wrote on 25.04.2005 21:26:32: > > Can you test the attached patch? It introduces a new option named > > "trust-frame-pointer". Whenever you encounter a problem you can: > > > > (gdb) set trust-frame-pointer 1 > > > > and try again. You probably want to reset it to 0 before continuing > > your program since I found out that bad things happen with some of the > > tests in the gdb testsuite with this turned on. > > I couldn't resist and checkin out and compiling went without problems so > I tried it out immediately... I did run my gdbtest app again (the one I > posted > to the list on 20050418). Here are the results. As you will see immediately > it looks now differently. There is no longer a SleepEx() in the stack. > Instead there is no a Sleep() but unfortunately the frame gets duplicated > and afterwards gdb complains about a maybe corrupt stack. See attached > output. > > Roland > > gdb.exe ./gdbtest.exe > GNU gdb 6.3.50.20050426-cvs > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-cygwin"... > (gdb) r > Starting program: /tmp/gdbtest.exe > test gdb stack tracing during a crash > Created thread 1 with ID: 2472 > I am thread 1 and alive > Created thread 2 with ID: 2292 > I am thread 2 and alive > Thread 1: var = 22 > Created thread 3 with ID: 2728 > I am thread 3 and alive > Thread 2: var = 21 > Created 3 Threads.... > Thread 1: var = 20 > Thread 3: var = 19 > Thread 2: var = 18 > Thread 1: var = 17 > Thread 3: var = 16 > Thread 2: var = 15 > Thread 1: var = 14 > Thread 3: var = 13 > Thread 1: var = 14 > Thread 3: var = 13 > Thread 2: var = 12 > Thread 1: var = 11 > Thread 3: var = 10 > Thread 2: var = 9 > Thread 1: var = 8 > Thread 3: var = 7 > Thread 2: var = 6 > Thread 1: var = 5 > Thread 3: var = 4 > Thread 2: var = 3 > Thread 1: var = 2 > Thread 3: var = 1 > I am thread 2 and I will crash now! > > Program received signal SIGSEGV, Segmentation fault. > [Switching to thread 2832.0x8f4] > 0x0040131d in crashIfZero (num=2) at gdbtest.c:17 > 17 *data=911; > (gdb) thr 1 > [Switching to thread 1 (thread 2832.0x97c)]#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 > (gdb) set trust-frame-pointer 1 > (gdb) bt > #0 0x7c91eb94 in ntdll!LdrAccessResource () from ntdll.dll > #1 0x7c91d85c in ntdll!ZwDelayExecution () from ntdll.dll > #2 0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll > #3 0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll > Previous frame identical to this frame (corrupt stack?) > (gdb) thr 2 > [Switching to thread 2 (thread 2832.0x9a8)]#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 0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll > #3 0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll > Previous frame identical to this frame (corrupt stack?) > (gdb) thr 3 > [Switching to thread 3 (thread 2832.0x8f4)]#0 0x0040131d in crashIfZero > (num=2) at gdbtest.c:17 > 17 *data=911; > (gdb) bt > #0 0x0040131d in crashIfZero (num=2) at gdbtest.c:17 > #1 0x00401363 in func4 (num=2) at gdbtest.c:26 > #2 0x0040139b in func3 (num=2) at gdbtest.c:34 > #3 0x004013c8 in func2 (num=2) at gdbtest.c:41 > #4 0x004013f5 in func1 (num=2) at gdbtest.c:48 > #5 0x0040136e in func4 (num=2) at gdbtest.c:27 > #6 0x0040139b in func3 (num=2) at gdbtest.c:34 > #7 0x004013c8 in func2 (num=2) at gdbtest.c:41 > #8 0x004013f5 in func1 (num=2) at gdbtest.c:48 > #9 0x00401436 in threadFunc (param=0x22ff58) at gdbtest.c:55 > #10 0x7c80b50b in KERNEL32!GetModuleFileNameA () from > /vol/c/WINDOWS/system32/kernel32.dll > #11 0x00000000 in ?? () from > (gdb) thr 4 > [Switching to thread 4 (thread 2832.0xaa8)]#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 0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll > #3 0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll > Previous frame identical to this frame (corrupt stack?) > (gdb) >