Message-ID: <4BEC7EAE.9020303@yahoo.com>
Date: Thu, 13 May 2010 15:35:26 -0700
From: Rob Donovan <hikerman2005-542731@yahoo.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: cygwin <cygwin@cygwin.com>
Subject: Cygwin, abort(), dlls and (useless?) coredumps.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

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