To: cygwin@cygwin.com
From: jojelino <jojelino@gmail.com>
Subject: Re: Interpreting a gdb backtrace
Date: Sat, 19 May 2012 10:14:31 +0900
Lines: 28
Message-ID: <jp6s5o$d21$1@dough.gmane.org>
References: <4FB6BA5F.6060906@cornell.edu> <jp6jdu$o7l$1@dough.gmane.org> <4FB6E993.2010601@cornell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:15.0) Gecko/15.0 Thunderbird/15.0a1
In-Reply-To: <4FB6E993.2010601@cornell.edu>
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 2012-05-19 AM 9:30, Ken Brown wrote:
>
> I built emacs with -g -O0.  gdb had the symbol table at the start of the
> debugging session.  It's just after the crash that everything is messed up.
>
> Ken
>
>
Then, i suspect that some function is called with function pointer type 
with different calling convention from itself, eventually stack frame is 
broken and return address goes into wrong place.
if it is the case, there is nothing we can expect from gdb backtrace. 
but at least we can inspect esp register ?? for example, type following
x $esp
x $esp-4
x $esp-8
x $esp-c ...
or
x $esp-0x40(or greater than) and just enter until you get value which 
seems to be return address.
and you can know what the return address is supposed to be(if it isn't 
relocated but it is scarce.)
i hope you can find return address. then you can breakpoint the annoying 
procedure.
-- 
Regards.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple