Discussion:
1.5.24-2: unalbe to get a core Dump file
Massimo Carboni
2007-12-05 10:48:33 UTC
Permalink
Hi there,

I'm quite new on cygwin I'm trying to get a core dump for debug purpose
without success.
My main necessity is related to a fortran code but I get the same result
also with C code.
Have someone any suggestion and/or solution?
Many thanks in advance,
Massimo Carboni

I wrote a simple C file:
*
main () {

float result;
result = 5/0;
}
*
I compile it with *gcc version 3.4.4 (cygming special, gdc 0.12, using
dmd 0.125)*
*
# gcc -Wall foo.c
*/foo.c:1: warning: return type defaults to `int'
foo.c: In function `main':
foo.c:4: warning: division by zero
foo.c:5: warning: control reaches end of non-void function
/*
# setenv CYGWIN "error_start=C:\cygwin\bin\dump.cmd"*

where*:
$ cat /bin/dump.cmd
c:\cygwin\bin\dumper.exe
*
when I run *a.exe *I got:

*$ ./a.exe
*** starting debugger for pid 3412, tid 3056
3 [main] a 3600 try_to_debug: Failed to start debugger, Win32 error 5
*** continuing pid 3412 from debugger call (0)
*
the system produce a .file:* a.exe.stackdump *that contain the following
information*

$ cat a.exe.stackdump
Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at eip=00401089
eax=00000005 ebx=00000000 ecx=00000001 edx=00000000 esi=611001A0
edi=00401350
ebp=0022CCE8 esp=0022CCD0
program=C:\cygwin\home\carboni\FLUKA\TEST\a.exe, pid 3600, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0022CCE8 00401089 (00000001, 61168928, 00660090, 0022CC70)
0022CD98 61006198 (00000000, 0022CDD0, 61005510, 0022CDD0)
61005510 61004416 (0000009C, A02404C7, E8611001, FFFFFF48)
208009 [main] a 3600 _cygtls::handle_exceptions: Error while dumping
state (probably corrupted stack)
*** starting debugger for pid 3412, tid 3056
224861 [main] a 3600 try_to_debug: Failed to start debugger, Win32 error 5
*** continuing pid 3412 from debugger call (0)



*
Alberto Luaces
2007-12-05 11:09:36 UTC
Permalink
Post by Massimo Carboni
Hi there,
I'm quite new on cygwin I'm trying to get a core dump for debug purpose
without success.
I think currently it is not possible to get the core file. However, you can
set the debugger to attach to the process when it crashes, which is basically
the same:

$ export CYGWIN=error_start=c:\\cygwin\\bin\\gdb.exe

(Change the path to point where your gdb.exe is).
Larry Hall (Cygwin)
2007-12-05 13:11:42 UTC
Permalink
Post by Alberto Luaces
Post by Massimo Carboni
Hi there,
I'm quite new on cygwin I'm trying to get a core dump for debug purpose
without success.
I think currently it is not possible to get the core file.
Actually, you can. See:

<http://cygwin.com/cygwin-ug-net/using-utils.html#dumper>
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
Post by Alberto Luaces
Q: Are you sure?
Post by Massimo Carboni
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Alberto Luaces
2007-12-05 14:39:34 UTC
Permalink
Post by Larry Hall (Cygwin)
Post by Alberto Luaces
Post by Massimo Carboni
I'm quite new on cygwin I'm trying to get a core dump for debug purpose
without success.
I think currently it is not possible to get the core file.
<http://cygwin.com/cygwin-ug-net/using-utils.html#dumper>
I said that because it seems dumper is broken:

http://thread.gmane.org/gmane.os.cygwin/92797/focus=92874

and

http://thread.gmane.org/gmane.os.cygwin/92797/focus=92874
Alberto Luaces
2007-12-05 14:43:04 UTC
Permalink
Post by Larry Hall (Cygwin)
Post by Alberto Luaces
Post by Massimo Carboni
I'm quite new on cygwin I'm trying to get a core dump for debug
purpose without success.
I think currently it is not possible to get the core file.
<http://cygwin.com/cygwin-ug-net/using-utils.html#dumper>
Sorry, this is the correct URL to the thread:

http://thread.gmane.org/gmane.os.cygwin/92797
Corinna Vinschen
2007-12-05 15:33:55 UTC
Permalink
Post by Alberto Luaces
Post by Larry Hall (Cygwin)
Post by Alberto Luaces
Post by Massimo Carboni
I'm quite new on cygwin I'm trying to get a core dump for debug
purpose without success.
I think currently it is not possible to get the core file.
<http://cygwin.com/cygwin-ug-net/using-utils.html#dumper>
http://thread.gmane.org/gmane.os.cygwin/92797
Did you try dumper from the experimental 1.5.25-3 package? Did you use
a newer GDB from CVS? If that doesn't help, http://cygwin.com/acronyms/#PTC


Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Alberto Luaces
2007-12-05 16:33:47 UTC
Permalink
Post by Corinna Vinschen
Post by Alberto Luaces
Post by Larry Hall (Cygwin)
Post by Alberto Luaces
Post by Massimo Carboni
I'm quite new on cygwin I'm trying to get a core dump for debug
purpose without success.
I think currently it is not possible to get the core file.
<http://cygwin.com/cygwin-ug-net/using-utils.html#dumper>
http://thread.gmane.org/gmane.os.cygwin/92797
Did you try dumper from the experimental 1.5.25-3 package?
Yes. No joy.
Post by Corinna Vinschen
Did you use
a newer GDB from CVS?
I do not see the relationship between gdb and dumper. The OP wanted to get a
core dump file, and dumper freezes before a core is generated for gdb to
read. That is why I recommended him to attach directly gdb to the process at
crash time instead of trying to get the core file.

If you mentioned that because of my thread, then I must say that no, I have
not tried the CVS version. I am doing my debugging in 32 bit instead.
Post by Corinna Vinschen
If that doesn't help,
http://cygwin.com/acronyms/#PTC
I gladly would like to submit as many patches as necessary, but unfortunately
I still have about fifteen years or so of learning before I could help in
such a complex project like gdb. I am instead trying to track some bugs into
the Cygwin's version of the OpenSceneGraph library, that is why I found those
difficulties.
Brian Dessent
2007-12-05 17:52:24 UTC
Permalink
Post by Massimo Carboni
# setenv CYGWIN "error_start=C:\cygwin\bin\dump.cmd"*
*** starting debugger for pid 3412, tid 3056
3 [main] a 3600 try_to_debug: Failed to start debugger, Win32 error 5
*** continuing pid 3412 from debugger call (0)
You can't use a .cmd file as the error_start parameter. It has to be a
directly executable binary. A cmd file is not directly executable, as
it has to be launched with %comspec% and that knowledge requires a
higher level API like ShellExecute instead of the low level
CreateProcess that is used here.

As already mentioned downthread, if you want a core dump you should
simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs
(which should have all been fixed in the latest version.)

If you really must run a cmd file, then you need to create an .exe
wrapper program that execs %comspec% /c "dump.cmd (original args)" or
similar.

Brian
Pedro Alves
2007-12-05 23:13:26 UTC
Permalink
Post by Brian Dessent
As already mentioned downthread, if you want a core dump you should
simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs
(which should have all been fixed in the latest version.)
The cvs version still doesn't work for me if I link
it with the distributed bfd -- it crashes in that case.
The latest fixes were done with a bfd from cvs.

I haven't tried the latest test version, but
should have the same problem.
--
Pedro Alves
Corinna Vinschen
2007-12-06 11:01:46 UTC
Permalink
Post by Pedro Alves
Post by Brian Dessent
As already mentioned downthread, if you want a core dump you should
simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs
(which should have all been fixed in the latest version.)
The cvs version still doesn't work for me if I link
it with the distributed bfd -- it crashes in that case.
The latest fixes were done with a bfd from cvs.
I haven't tried the latest test version, but
should have the same problem.
Do you imply that we need a new binutils package to get dumper working?


Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Corinna Vinschen
2007-12-06 11:44:38 UTC
Permalink
Post by Corinna Vinschen
Post by Pedro Alves
Post by Brian Dessent
As already mentioned downthread, if you want a core dump you should
simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs
(which should have all been fixed in the latest version.)
The cvs version still doesn't work for me if I link
it with the distributed bfd -- it crashes in that case.
The latest fixes were done with a bfd from cvs.
I haven't tried the latest test version, but
should have the same problem.
Do you imply that we need a new binutils package to get dumper working?
I just built dumper with a bfd from CVS HEAD(*). It seems to work on
the first glance. Setting error_start as above, it catches the division
by zero from the OP's test app and creates a core file. However, this
core file doesn't seem to be very helpful, at least when using GDB from
the distro:

(gdb) i thr
3 process 1984 0x7c95077b in ntdll!KiIntSystemCall ()
from /mnt/c/WINDOWS/system32/ntdll.dll
2 process 3020 0x7c90eb94 in ntdll!LdrAccessResource ()
from /mnt/c/WINDOWS/system32/ntdll.dll
* 1 process 3836 0x7c90eb94 in ntdll!LdrAccessResource ()
from /mnt/c/WINDOWS/system32/ntdll.dll

None of the backtraces shows anything beyond the system DLLs.

Do we also need a newer GDB for this to be useful?


Corinna


(*) Btw., the new testrelease 1.5.24-4 contains this dumper.exe
linked against bfd from CVS HEAD.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Christopher Faylor
2007-12-06 12:22:13 UTC
Permalink
Post by Corinna Vinschen
Post by Corinna Vinschen
Post by Pedro Alves
Post by Brian Dessent
As already mentioned downthread, if you want a core dump you should
simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs
(which should have all been fixed in the latest version.)
The cvs version still doesn't work for me if I link
it with the distributed bfd -- it crashes in that case.
The latest fixes were done with a bfd from cvs.
I haven't tried the latest test version, but
should have the same problem.
Do you imply that we need a new binutils package to get dumper working?
I just built dumper with a bfd from CVS HEAD(*). It seems to work on
the first glance. Setting error_start as above, it catches the division
by zero from the OP's test app and creates a core file. However, this
core file doesn't seem to be very helpful, at least when using GDB from
(gdb) i thr
3 process 1984 0x7c95077b in ntdll!KiIntSystemCall ()
from /mnt/c/WINDOWS/system32/ntdll.dll
2 process 3020 0x7c90eb94 in ntdll!LdrAccessResource ()
from /mnt/c/WINDOWS/system32/ntdll.dll
* 1 process 3836 0x7c90eb94 in ntdll!LdrAccessResource ()
from /mnt/c/WINDOWS/system32/ntdll.dll
None of the backtraces shows anything beyond the system DLLs.
Do we also need a newer GDB for this to be useful?
I'm not aware of any advances in frame handling in the CVS version of gdb
but I'm waiting for the recent spate of win32 activity to die down before
I release a new version of gdb.

cgf
Corinna Vinschen
2007-12-06 12:55:54 UTC
Permalink
Post by Christopher Faylor
Post by Corinna Vinschen
Post by Corinna Vinschen
Post by Pedro Alves
Post by Brian Dessent
As already mentioned downthread, if you want a core dump you should
simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs
(which should have all been fixed in the latest version.)
The cvs version still doesn't work for me if I link
it with the distributed bfd -- it crashes in that case.
The latest fixes were done with a bfd from cvs.
I haven't tried the latest test version, but
should have the same problem.
Do you imply that we need a new binutils package to get dumper working?
I just built dumper with a bfd from CVS HEAD(*). It seems to work on
the first glance. Setting error_start as above, it catches the division
by zero from the OP's test app and creates a core file. However, this
core file doesn't seem to be very helpful, at least when using GDB from
(gdb) i thr
3 process 1984 0x7c95077b in ntdll!KiIntSystemCall ()
from /mnt/c/WINDOWS/system32/ntdll.dll
2 process 3020 0x7c90eb94 in ntdll!LdrAccessResource ()
from /mnt/c/WINDOWS/system32/ntdll.dll
* 1 process 3836 0x7c90eb94 in ntdll!LdrAccessResource ()
from /mnt/c/WINDOWS/system32/ntdll.dll
None of the backtraces shows anything beyond the system DLLs.
Do we also need a newer GDB for this to be useful?
I'm not aware of any advances in frame handling in the CVS version of gdb
but I'm waiting for the recent spate of win32 activity to die down before
I release a new version of gdb.
That makes sense. A new binutils package might be helpful, though.


Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Loading...