backtrace/2447: Cannot produce backtraces for Cygwin programs

backtrace/2447: Cannot produce backtraces for Cygwin programs

[jim]

>Number:         2447
>Category:       backtrace
>Synopsis:       Cannot produce backtraces for Cygwin programs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 14 19:28:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     jim@jimrandomh.org
>Release:        6.8.0.20080328-cvs (cygwin-special)
>Organization:
>Environment:
Cygwin 1.5.25-11
>Description:
Under Cygwin, GDB produces incorrect backtraces whenever a C or C++ program calls abort(), either directly or by calling assert(0), throwing a C++ exception which is not caught, or free()ing the same pointer or twice. This makes it pretty useless, since these are the majority of crashes.

[jbabcock@timewarp test]$ more test.c
#include <assert.h>
int main() { assert(0); }
[jbabcock@timewarp test]$ gcc -o test test.c
[jbabcock@timewarp test]$ gcc --version
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[jbabcock@timewarp test]$ gdb test.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(no debugging symbols found)
(gdb) run
Starting program: /home/jbabcock/src/guish/util/test/test.exe
[New thread 2996.0xcb0]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New thread 2996.0x72c]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
assertion "0" failed: file "test.c", line 2

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2996.0x72c]
0x610165b3 in stack_info::walk () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x610165b3 in stack_info::walk () from /usr/bin/cygwin1.dll
#1  0x7c859dcc in OutputDebugStringA () from /WINDOWS/system32/kernel32.dll
#2  0x40010006 in ?? ()
#3  0x00000000 in ?? ()
(gdb) info threads
* 2 thread 2996.0x72c  0x610165b3 in stack_info::walk () from /usr/bin/cygwin1.dll
  1 thread 2996.0xcb0  0x7c90eb94 in ntdll!LdrAccessResource () from /WINDOWS/system32/ntdll.dll
warning: Couldn't restore frame in current thread, at frame 0
0x7c812a5b in RaiseException () from /WINDOWS/system32/kernel32.dll
(gdb) thread 1
[Switching to thread 1 (thread 2996.0xcb0)]#0  0x7c90eb94 in ntdll!LdrAccessResource () from /WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c90eb94 in ntdll!LdrAccessResource () from /WINDOWS/system32/ntdll.dll
#1  0x7c90e9c0 in ntdll!ZwWaitForSingleObject () from /WINDOWS/system32/ntdll.dll
#2  0x7c8025cb in WaitForSingleObjectEx () from /WINDOWS/system32/kernel32.dll
#3  0x00000700 in ?? ()
#4  0x00000000 in ?? ()
>How-To-Repeat:
Install Cygwin from cygwin.com including the gdb and gcc packages. Run this program inside gdb and ask for a backtrace:
#include <assert.h>
int main() { assert(0); }
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: backtrace/2447: Cannot produce backtraces for Cygwin programs

[Daniel Jacobowitz]

The following reply was made to PR backtrace/2447; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: jim@jimrandomh.org
Cc: gdb-gnats@sources.redhat.com
Subject: Re: backtrace/2447: Cannot produce backtraces for Cygwin programs
Date: Mon, 14 Apr 2008 16:03:01 -0400

 On Mon, Apr 14, 2008 at 07:25:36PM -0000, jim@jimrandomh.org wrote:
 > Under Cygwin, GDB produces incorrect backtraces whenever a C or C++
 > program calls abort(), either directly or by calling assert(0),
 > throwing a C++ exception which is not caught, or free()ing the same
 > pointer or twice. This makes it pretty useless, since these are the
 > majority of crashes.
 
 Thanks for the report.  Unfortunately improving backtraces
 through the MS DLLs is a very hard project, that so far no one
 has been able to solve for GDB.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery