X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Message-ID: <4893506C.AF441DDE@dessent.net> Date: Fri, 01 Aug 2008 11:05:32 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: Steve Waldo CC: cygwin AT cygwin DOT com Subject: Re: seg fault produces stackdump with no stack trace References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com 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 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 0x00000000 is because that is not a valid program location. But it can give you a backtrace, you're just not asking for it: $ gdb --quiet a.exe (gdb) r [New thread 2912.0x544] [New thread 2912.0xaf0] Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x00401052 in letsCrash () at tc.c:4 #2 0x00401083 in main () at tc.c:9 (gdb) Brian -- 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/