X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Steve Waldo <steven DOT j DOT waldo AT seagate DOT com>
Subject:	Re: seg fault produces stackdump with no stack trace
Date:	Fri, 1 Aug 2008 17:55:24 +0000 (UTC)
Lines:	27
Message-ID:	<loom.20080801T174446-165@post.gmane.org>
References:	<loom DOT 20080801T151340-446 AT post DOT gmane DOT org>
Mime-Version:	1.0
User-Agent:	Loom/3.14 (http://gmane.org/)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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 following message at crash time:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) 

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.

The real crash is occurring too intermittently to catch it in the debugger. 
That's why I was hoping for a stack trace, so I could at least know which 
function to set a breakpoint in.

Thanks again,
--Steve


--
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/

- Raw text -