Christopher Faylor writes:
> I just checked in a fix which should keep the stack trace going even
> when it finds a return address of zero.
That'll be great. Thanks much!
--Steve
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problem
Brian Dessent dessent.net> writes:
> (gdb) bt
> #0 0x in ?? ()
> #1 0x00401052 in letsCrash () at tc.c:4
> #2 0x00401083 in main () at tc.c:9
> (gdb)
Many thanks Brian! 'bt' was what I'd forgotten. Sorry about the newbie
mistake - I haven't used gdb in ages. I'm actually using 'ddd'
Thanks to all for your prompt replies! Much appreciated.
I'm amazed that the stack trace is so wimpy. All I did to trigger the example
was to add a call to this function to intentionally crash:
int letsCrash()
{
int (*myfunc)() = 0;
return myfunc();
}
With the debugger, it produces the fo
Hello,
I've seen other postings that show stackdump examples that include the
expected list of addresses in the stack trace. I'm not getting that list. When
my app gets a seg fault it produces the expected stackdump file:
[1]- Segmentation fault (core dumped) ./ResourceMgr
but the result
4 matches
Mail list logo
