From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Roxborough <irox@redhat.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: insight@sources.redhat.com
Subject: Re: Stack Window Problem [was: Re: DLLs and Insight...]
Date: Thu, 01 Nov 2001 12:44:00 -0000
Message-id: <3BE1B6FA.DC941BC0@redhat.com>
References: <3BD5A9E0.F58D0D66@redhat.com> <20011023140707.D23357@redhat.com> <3BE036A6.DBBBB5E2@redhat.com> <3BE04753.4AA1A1B9@redhat.com> <3BE054E0.9EAA172@redhat.com> <3BE1A584.C00E8BB9@cygnus.com>
X-SW-Source: 2001-q4/msg00248.html

Hi,

It seems to just get stranger the more I look at it.

So, I'm trying to reproduce the problem but at a different
point in execution and it happens slightly differently:

All the entries in the start look correct (i.e., no "??" entries).
But on closer examination some of the stack entries are totally
wrong, for example Tcl_DStringSetLength is calling Tcl_Realloc,
but the stack shows it as calling Tk_FreePixmap.  However if I
click on the "Tk_FreePixmap" entry in the stack window to view
the source I am taken to the correct place (i.e. Tcl_Realloc source code).
A little bit farther down the stack "realloc" is called.  If I
click on the "realloc" stack entry to see the source code I am
taken to line 1810 of tkMenu.c in the function PostProcessEntry.

I get the same results using "gdb -nw".

Here is how I am reproducing this problem:

-> ./gdb ./gdb.exe
-> break Tcl_Realloc
-> run
-> bt
{Notice that everything should be normal}
-> s
{We change stack levels}
-> bt
{The stack frame called "Tcl_Realloc" is
 now called "Tk_FreePixmap"}

Does anybody else have a current up-to-date Windows build
they could try to reproduce this with?  With Windows it's
hard to tell if it's something specific to my machine
or the code.

Thanks,

 Ian.

Fernando Nasser wrote:
> 
> Ian Roxborough wrote:
> >
> > bt shows the same as the Insight stack window, i.e. stack
> > frames inside1 the Tk DLL are shown as "??".  Running gdb
> > using the "-nw" flags gives the same results.
> >
> 
> This ascertains that the GUI is innocent :)
> 
> That said, lets see how we can track this down.
> 
> > If it is stack corruption, would it be normal to vary between
> > similar versions of gdb?
> >
> 
> I've never seen the bt output.  Re-reading your message it seems
> that you got a sane stack trace -- just the symbolic information
> for the portions that are inside the Tk DLL are missing, right?
> 
> (Maybe you should post the bt output)
> 
> In the past, I had to manually load the DLL symbols in gdb.
> After making sure the DLL compiled with debugging symbols
> was the only one around and after stopping somewhere after
> it was loaded, I used the add-symbol command to load the
> DLL symbols in.  After that was done, the backtrace had
> all symbolic info on it.
> 
> You'll need the load address of the dll.  The syntax is:
> 
> add-symbol filename address
> 
> --
> Fernando Nasser
> Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9