X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Steve Waldo Subject: Re: seg fault produces stackdump with no stack trace Date: Fri, 1 Aug 2008 17:55:24 +0000 (UTC) Lines: 27 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: List-Subscribe: List-Archive: List-Post: List-Help: , 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/