This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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,


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]