On Fri, Apr 10, 2009 at 02:28:49PM -0700, Tarmik wrote:
>>I just checked in a fix which should keep the stack trace going even
>>when it finds a return address of zero.
>
>>It will be in the next cygwin snapshot at: http://cygwin.com/snapshots/
>>but be advised that this is a 1.7.x version of Cygwi
this message in context:
http://www.nabble.com/seg-fault-produces-stackdump-with-no-stack-trace-tp18777069p22994946.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/pro
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
On Fri, Aug 01, 2008 at 05:55:24PM +, Steve Waldo wrote:
>Thanks to all for your prompt replies! Much appreciated.
>
>I'm amazed that the stack trace is so wimpy.
You're right. The algorithm isn't really sophisticated but it shouldn't
be quite that bad.
I just checked in a fix which should k
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'
Steve Waldo wrote on 01 August 2008 18:55:
> The real crash is occurring too intermittently to catch it in the
> debugger.
You need the 'error_start' option of the CYGWIN environment variable;
check the cygwin user's guide for more info.
cheers,
DaveK
--
Can't think of a witty .sig
Steve Waldo wrote:
> Even the debugger didn't know where it was anymore! It's obvious in this case
> why it went off in the weeds, but I would have thought the stack would still
> be accessible.
Well of *course* the debugger doesn't know what 0x is because
that is not a valid program loca
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
On Fri, Aug 01, 2008 at 03:24:26PM +, Steve Waldo wrote:
>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]- Segmenta
Steve Waldo wrote:
> but the resulting file contains no stack trace:
>
> $ cat ResourceMgr.exe.stackdump
> Exception: STATUS_ACCESS_VIOLATION at eip=
Right there you should see the problem. eip=0 means your program has
followed a null pointer and wandered off into lala land, so you
shou
Steve Waldo wrote on 01 August 2008 16:24:
> When my app gets a seg fault it produces the expected stackdump file:
>
> [1]- Segmentation fault (core dumped) ./ResourceMgr
>
> but the resulting file contains no stack trace:
> Is there a setting I'm missing somewhere?
Nah, it probably j
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
12 matches
Mail list logo
