Hi Christopher,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.
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/
