X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Message-ID: <48932FEB.54CAB98A@dessent.net> Date: Fri, 01 Aug 2008 08:46:51 -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: > but the resulting file contains no stack trace: > > $ cat ResourceMgr.exe.stackdump > Exception: STATUS_ACCESS_VIOLATION at eip=00000000 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 shouldn't be surprised that this unwinder can't do anything, as this probably triggers an internal "stop, something's wrong" check because eip=0 cannot possibly be a correct frame. The unwinder used here is very primitive, it only knows how to unwind a standard frame layout. It does not use anything sophisticated like unwind tables or debug info, and it will be totally stymied if a frame uses FPO/-fomit-frame-pointer style optimizations where the return address is not at 4(%ebp). 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/