This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Cygwin, abort(), dlls and (useless?) coredumps.
- From: Rob Donovan <hikerman2005-542731 at yahoo dot com>
- To: cygwin <cygwin at cygwin dot com>
- Date: Thu, 13 May 2010 15:35:26 -0700
- Subject: Cygwin, abort(), dlls and (useless?) coredumps.
I have error_start=c:\cygwin\bin\dumper.exe set in my CYGWIN environment
variable and as a result the following code coredumps:
// gcc -g -o core.x core.c
int main (int argc, char *argv[])
{
long x;
x = 1;
abort();
return(0);
}
Loading the coredump into gdb and entering the command "thread apply all
bt" produces the output below. My problem is that the backtrace on
every thread seems to be stuck in Windows dlls. Nowhere can I find out
anything about the value of x, which is what I'd like to do. Is there
any way around this?
[I did try replacing abort() with a call to myabort() which calls
dumper.exe directly via a system() call, but this doesn't really improve
things - backtrace gets stuck in Cygwin dlls instead. [I first tried
trapping the call to abort() with signal() then calling dumper.exe via
system(), and that didn't help either...]]
I don't think this behaviour is limited to abort() generated coredumps;
I'm pretty sure I've seen it with segmentation fault generated coredumps
too.
Thanks
Rob Donovan
bash-3.2$ gdb core.x core.x.core
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"...
warning: core file may not match specified executable file.
Reading symbols from /cygdrive/c/WINDOWS/system32/ntdll.dll...done.
Loaded symbols for C:\WINDOWS\system32\ntdll.dll
Reading symbols from /cygdrive/c/WINDOWS/system32/kernel32.dll...done.
Loaded symbols for C:\WINDOWS\system32\kernel32.dll
Reading symbols from /cygdrive/c/cygwin/bin/cygwin1.dll...done.
Loaded symbols for C:\cygwin\bin\cygwin1.dll
Reading symbols from /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL...done.
Loaded symbols for C:\WINDOWS\system32\ADVAPI32.DLL
Reading symbols from /cygdrive/c/WINDOWS/system32/RPCRT4.dll...done.
Loaded symbols for C:\WINDOWS\system32\RPCRT4.dll
Reading symbols from /cygdrive/c/WINDOWS/system32/Secur32.dll...done.
Loaded symbols for C:\WINDOWS\system32\Secur32.dll
[New process 1]
[New process 0]
[New process 0]
#0 0x7c90e514 in ntdll!LdrAccessResource () from
C:\WINDOWS\system32\ntdll.dll
(gdb) thread apply all bt
Thread 3 (process 0):
#0 0x7c90e514 in ntdll!LdrAccessResource () from
C:\WINDOWS\system32\ntdll.dll
#1 0x7c90df5a in ntdll!ZwWaitForSingleObject () from
C:\WINDOWS\system32\ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from
C:\WINDOWS\system32\kernel32.dll
#3 0x000007cc in ?? ()
#4 0x00000000 in ?? ()
Thread 2 (process 0):
#0 0x7c90e514 in ntdll!LdrAccessResource () from
C:\WINDOWS\system32\ntdll.dll
#1 0x7c90df5a in ntdll!ZwWaitForSingleObject () from
C:\WINDOWS\system32\ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from
C:\WINDOWS\system32\kernel32.dll
#3 0x000007cc in ?? ()
#4 0x00000000 in ?? ()
Thread 1 (process 1):
#0 0x7c90e514 in ntdll!LdrAccessResource () from
C:\WINDOWS\system32\ntdll.dll
#1 0x7c90df5a in ntdll!ZwWaitForSingleObject () from
C:\WINDOWS\system32\ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from
C:\WINDOWS\system32\kernel32.dll
#3 0x000007cc in ?? ()
#4 0x00000000 in ?? ()
(gdb)
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple