This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: help: dumper 1.10 not giving expected stack trace in gdb
Christopher Faylor wrote:
The core dump occurred in a function which does not have a frame pointer.
This screws up stack dumps on x86 systems. There isn't really much that
you can do about this.
Hi Christopher,
Thanks for the reply. I guess what I don't understand is, if I don't set
error_start to dumper, I get what appears to be a nice stack trace in
the t.exe.stackdump file:
Stack trace:
Frame Function Args
0022FE38 6106F232 (00000DD4, 00000006, 0022FEA8, 0040120D)
0022FE88 6106F3B0 (00000DD4, 00000006, 0022FED8, 6106F965)
0022FE98 6106F2FC (00000006, 00000006, 0022FEC8, 61003A31)
0022FED8 6106F965 (0022FEF0, 610850F8, 610F063C, 00000000)
0022FEF0 00401073 (00000001, 6160214C, 0A040330, 0022FF24)
0022FF40 61005018 (610CFEE0, FFFFFFFE, 000007E4, 610CFE04)
0022FF90 610052ED (00000000, 00000000, 00000001, 00000000)
0022FFB0 00401401 (00401050, 037F0009, 0022FFF0, 77E814C7)
0022FFC0 0040103C (00000001, 00000017, 7FFDF000, F3583CF0)
0022FFF0 77E814C7 (00401000, 00000000, 78746341, 00000020)
End of stack trace
The "Frame" column is a frame pointer, isn't it? I loaded t.exe into gdb
and checked out some of the addresses via x/i. The functions look
perfectly reasonable.
When I set error_start to dumper.exe, the very same program produces a
core file which apparently does not correspond to the stackdump
information at all.
So my question now is, why would dumper produce a "bad" core file, while
without dumper, cygwin generates a "good" stackdump file?
Thanks for any help,
--Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/