DLLs and Insight...

DLLs and Insight...

[Ian Roxborough]

Hi,
 
I'm wondering about debugging inside a DLL loaded into an application.
I'm getting a little closer to the Windows crashing problems, but I 
can't see an debug symbols or sources when I'm debugging inside the
Tk DLL.  The stack shows "???" as calls into the Tk DLL.

I'm not sure if I've mis-compiled Tk some how, or if there is a
trick to loading the DLL into Insight after you start debugging
the application.  Any clues?

 Thanks again,

   Ian.

Re: DLLs and Insight...

[Keith Seitz]

On Tue, 23 Oct 2001, Ian Roxborough wrote:

> I'm wondering about debugging inside a DLL loaded into an application.
> I'm getting a little closer to the Windows crashing problems, but I
> can't see an debug symbols or sources when I'm debugging inside the
> Tk DLL.  The stack shows "???" as calls into the Tk DLL.

Are you stepping into the function or setting a breakpoint at a function?
You could be stuck in prologue or something.

> I'm not sure if I've mis-compiled Tk some how, or if there is a
> trick to loading the DLL into Insight after you start debugging
> the application.  Any clues?

To check if you are using a DLL with no debug info, you should open a
console window and type "info func TK_FUNC", where TK_FUNC is the name of
any Tk function in the dll. If it comes up as "non-debugging symbols",
you'll know that you've got no debugging on the DLL. You should also make
sure that Tk is compiled without -O2.

Otherwise, DLLs should just work. I've never had to do anything special
for them.
Keith

FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Ian Roxborough]

Hi,

well, I deleted my build tree, did a clean build and
was able to see sources/debug symbols from DLLs in Insight.
I probably had it working but didn't actually start the
application to load the symbol info into Insight first
time around.  Thanks for all the pointers and help.

And soon after that I found a breakpoint related bug.
If I try to set a breakpoint in a DLL using the Function Browser
(actually, even if I set it in the console) it sets the
breakpoint at the same line but in some other file (which
was loaded at start up).  This seems related to the Tcl/Tk
upgrade since I tried it with a version of Insight built
using Tcl/Tk8.0 and wasn't able to reproduce the problem.

Ian.

Re: FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Keith Seitz]

On Tue, 23 Oct 2001, Ian Roxborough wrote:

> If I try to set a breakpoint in a DLL using the Function Browser
> (actually, even if I set it in the console) it sets the
> breakpoint at the same line but in some other file (which
> was loaded at start up).

Can you expound on this a little? If you can do this with the console
window, can you send a snippet from the console window showing what you
did? Did you try it without insight, i.e., gdb -nw?

Keith

Re: FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Ian Roxborough]

Keith Seitz wrote:
> 
> On Tue, 23 Oct 2001, Ian Roxborough wrote:
> 
> > If I try to set a breakpoint in a DLL using the Function Browser
> > (actually, even if I set it in the console) it sets the
> > breakpoint at the same line but in some other file (which
> > was loaded at start up).
> 
> Can you expound on this a little? If you can do this with the console
> window, can you send a snippet from the console window showing what you
> did? Did you try it without insight, i.e., gdb -nw?

It works with "gdb -nw".  

If in the console I type "break tkWinWm.c:4203" it replies that the breakpoint
is set at that location.  But if I look at the breakpoints window it lists
the breakpoint as being set in tclCompile.c at line 4203.  If I use the 
Function Browser to set the same breakpoint it sets it in tclCompile.c at
line 1109.

Ian.

Re: FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Keith Seitz]

On Tue, 23 Oct 2001, Ian Roxborough wrote:

> It works with "gdb -nw".

Joy. This means that the command-line does some magic that our breakpoint
interfaces don't handle.

> If in the console I type "break tkWinWm.c:4203" it replies that the breakpoint
> is set at that location.  But if I look at the breakpoints window it lists
> the breakpoint as being set in tclCompile.c at line 4203.  If I use the
> Function Browser to set the same breakpoint it sets it in tclCompile.c at
> line 1109.

This is odd. I would not expect entering the breakpoint at the console
prompt to change the breakpoint. Does "info break" show the right
location? What does "tk gdb_get_breakpoint_info BKPT#" show?

Keith

Re: FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Ian Roxborough]

Keith Seitz wrote:
> 
> On Tue, 23 Oct 2001, Ian Roxborough wrote:
> 
> > It works with "gdb -nw".
> 
> Joy. This means that the command-line does some magic that our breakpoint
> interfaces don't handle.
> 
> > If in the console I type "break tkWinWm.c:4203" it replies that the breakpoint
> > is set at that location.  But if I look at the breakpoints window it lists
> > the breakpoint as being set in tclCompile.c at line 4203.  If I use the
> > Function Browser to set the same breakpoint it sets it in tclCompile.c at
> > line 1109.
> 
> This is odd. I would not expect entering the breakpoint at the console
> prompt to change the breakpoint. Does "info break" show the right
> location? What does "tk gdb_get_breakpoint_info BKPT#" show?

Both show the same as the breakpoint window (i.e. the breakpoints set
in the wrong places).

Ian.

Re: FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Keith Seitz]

On Tue, 23 Oct 2001, Ian Roxborough wrote:

> > This is odd. I would not expect entering the breakpoint at the console
> > prompt to change the breakpoint. Does "info break" show the right
> > location? What does "tk gdb_get_breakpoint_info BKPT#" show?
>
> Both show the same as the breakpoint window (i.e. the breakpoints set
> in the wrong places).

My initial reaction to this is "it's not possible". Entering "break
foo.c:124" is the same whether or not its done at the command line or at
the console prompt. The only difference is that when Insight is around, an
event is sent to the gui.

I would expect to see problems with the Func Browser or the SrcWin, since
these use different mechanisms for setting breakpoints than the console
window.

Something really weird is going on, and I guess the only way to resolve it
is to debug it. I will see if I can get to it tonight.

Keith

Re: FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Ian Roxborough]

Keith Seitz wrote:
> 
> On Tue, 23 Oct 2001, Ian Roxborough wrote:
> 
> > > This is odd. I would not expect entering the breakpoint at the console
> > > prompt to change the breakpoint. Does "info break" show the right
> > > location? What does "tk gdb_get_breakpoint_info BKPT#" show?
> >
> > Both show the same as the breakpoint window (i.e. the breakpoints set
> > in the wrong places).
> 
> My initial reaction to this is "it's not possible". Entering "break
> foo.c:124" is the same whether or not its done at the command line or at
> the console prompt. The only difference is that when Insight is around, an
> event is sent to the gui.
>
> I would expect to see problems with the Func Browser or the SrcWin, since
> these use different mechanisms for setting breakpoints than the console
> window.

Is there anything that resets the breakpoints for any reason?

The response from setting the breakpoint in the console would indicate
that the breakpoint was correctly set.  However, looking at the breakpoints
window or querying the breakpoint from the console says it's not.
 
> Something really weird is going on, and I guess the only way to resolve it
> is to debug it. I will see if I can get to it tonight.

Sure, the crashing problem might be a bit annoying, but shouldn't stop you
looking at that part of Insight.  Hmmmm, maybe I should build Insight with
Tcl/Tk8.4 and see if the problem still persists.

Ian.

Re: FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]

[Keith Seitz]

On Tue, 23 Oct 2001, Ian Roxborough wrote:

> > This is odd. I would not expect entering the breakpoint at the console
> > prompt to change the breakpoint. Does "info break" show the right
> > location? What does "tk gdb_get_breakpoint_info BKPT#" show?
>
> Both show the same as the breakpoint window (i.e. the breakpoints set
> in the wrong places).

I dunno. I can certainly reproduce this with the command line:

$ gdb.exe -q -nw -nx gdb.exe
(gdb) b main
Breakpoint 1 at 0x402116: file ../../src/gdb/main.c, line 698.
(gdb) r
Starting program:
/home/keiths/sources/built-net/H-i686-pc-cygwin/bint/gdb.exe

Breakpoint 1 main (argc=1, argv=0x10291348) at ../../src/gdb/main.c:698
698     {
(gdb) b tkWinWm.c:4023
Breakpoint 2 at 0x10021282: file ../../../src/tkwin/tkWinWm.c, line 4023.
(gdb) inf br
Num Type                  Disp  Enb Address     What
1   breakpoint            keep  y   0x00402116  in main at ../../src/gdb/main.c:698
2   breakpoint            keep  y   0x10021282  in DictionaryCompare
                                                at ../../../src/tk/win/tkWinWm.c:4023

(gdb) p DictionaryCompare
$2 = {int (char *, char*)} 0x5f8e88 (DictionaryCompare)
(gdb) p WmProc
$1 = {LRESULT (HWND, UINT, WPARAM, LPARAM)} 0x10021560 (WmProc@16)
(gdb) disass WmProc
[stuff from 0x10021560 - 0x100218dd]

So it would appear that the breakpoint was set at the right place, but gdb
reports the wrong function for it.

I think the reason this happens is because dlls symbols don't appear to be
relocated. "info shared" shows that cygtcl83.dll is loaded at 10001000,
while cygtk83.dll is at 00b7100. This cannot be correct, since WmProc is
in cygtk83.dll!

Maybe this has something to do with the WmProcs type? "static LRESULT
CALLBACK" -- I don't exactly know what they would do to the
compiler/linker.

I dunno. I'm outta ideas right now...
Keith

Re: DLLs and Insight...

[Fernando Nasser]

Ian Roxborough wrote:
> 
> Hi,
> 
> I'm wondering about debugging inside a DLL loaded into an application.
> I'm getting a little closer to the Windows crashing problems, but I
> can't see an debug symbols or sources when I'm debugging inside the
> Tk DLL.  The stack shows "???" as calls into the Tk DLL.
> 
> I'm not sure if I've mis-compiled Tk some how, or if there is a
> trick to loading the DLL into Insight after you start debugging
> the application.  Any clues?
> 

Have you tried attaching to it after making sure that the tk dll
was already loaded (rather than starting it from inside)?  
Or is this too late for what you're trying to debug?

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: DLLs and Insight...

[Christopher Faylor]

On Tue, Oct 23, 2001 at 10:33:20AM -0700, Ian Roxborough wrote:
>I'm wondering about debugging inside a DLL loaded into an application.
>I'm getting a little closer to the Windows crashing problems, but I
>can't see an debug symbols or sources when I'm debugging inside the Tk
>DLL.  The stack shows "???" as calls into the Tk DLL.

It sounds like there is no debugging info in the DLL.  Is it being
compiled/linked with -g?

cgf

Stack Window Problem [was: Re: DLLs and Insight...]

[Ian Roxborough]

Hi,

so I'm still slogging away at the Windows crashing problem and
then I had the problem where I couldn't see the source of the Tk
DLL again.

Problem: I'm running Insight and Tk segfaults (which I what I want),
but when I look at the stack all I see are "????" where I should
see Tk functions.  I can set breakpoints in Tk functions (which don't
work), I can browse Tk functions in the Function Browser, but can't
see them in drop down comboboxes in the Source Window.

It seems to me that this is and intermittent problem with Insight.
I checked it against at pre-Tcl8.3 Insight build and could see
all the stack entries without any problem.

Ian.


Christopher Faylor wrote:
> 
> On Tue, Oct 23, 2001 at 10:33:20AM -0700, Ian Roxborough wrote:
> >I'm wondering about debugging inside a DLL loaded into an application.
> >I'm getting a little closer to the Windows crashing problems, but I
> >can't see an debug symbols or sources when I'm debugging inside the Tk
> >DLL.  The stack shows "???" as calls into the Tk DLL.
> 
> It sounds like there is no debugging info in the DLL.  Is it being
> compiled/linked with -g?
> 
> cgf

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Fernando Nasser]

Ian Roxborough wrote:
> 
> Hi,
> 
> so I'm still slogging away at the Windows crashing problem and
> then I had the problem where I couldn't see the source of the Tk
> DLL again.
> 
> Problem: I'm running Insight and Tk segfaults (which I what I want),
> but when I look at the stack all I see are "????" where I should
> see Tk functions.  I can set breakpoints in Tk functions (which don't
> work), I can browse Tk functions in the Function Browser, but can't
> see them in drop down comboboxes in the Source Window.
> 
> It seems to me that this is and intermittent problem with Insight.
> I checked it against at pre-Tcl8.3 Insight build and could see
> all the stack entries without any problem.
> 

This is a common symptom of stack corruption as well.  What does the
command like "bt" command shows?  (try it in the console window, 
I don't think it matters not being in the real console).

Fernando


> Ian.
> 
> Christopher Faylor wrote:
> >
> > On Tue, Oct 23, 2001 at 10:33:20AM -0700, Ian Roxborough wrote:
> > >I'm wondering about debugging inside a DLL loaded into an application.
> > >I'm getting a little closer to the Windows crashing problems, but I
> > >can't see an debug symbols or sources when I'm debugging inside the Tk
> > >DLL.  The stack shows "???" as calls into the Tk DLL.
> >
> > It sounds like there is no debugging info in the DLL.  Is it being
> > compiled/linked with -g?
> >
> > cgf

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Ian Roxborough]

Fernando Nasser wrote:
> 
> Ian Roxborough wrote:
> >
> > Hi,
> >
> > so I'm still slogging away at the Windows crashing problem and
> > then I had the problem where I couldn't see the source of the Tk
> > DLL again.
> >
> > Problem: I'm running Insight and Tk segfaults (which I what I want),
> > but when I look at the stack all I see are "????" where I should
> > see Tk functions.  I can set breakpoints in Tk functions (which don't
> > work), I can browse Tk functions in the Function Browser, but can't
> > see them in drop down comboboxes in the Source Window.
> >
> > It seems to me that this is and intermittent problem with Insight.
> > I checked it against at pre-Tcl8.3 Insight build and could see
> > all the stack entries without any problem.
> >
> 
> This is a common symptom of stack corruption as well.  What does the
> command like "bt" command shows?  (try it in the console window,
> I don't think it matters not being in the real console).

bt shows the same as the Insight stack window, i.e. stack
frames inside the Tk DLL are shown as "??".  Running gdb
using the "-nw" flags gives the same results.

If it is stack corruption, would it be normal to vary between
similar versions of gdb?

Ian.

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Christopher Faylor]

On Wed, Oct 31, 2001 at 11:45:36AM -0800, Ian Roxborough wrote:
>Fernando Nasser wrote:
>> 
>> Ian Roxborough wrote:
>> >
>> > Hi,
>> >
>> > so I'm still slogging away at the Windows crashing problem and
>> > then I had the problem where I couldn't see the source of the Tk
>> > DLL again.
>> >
>> > Problem: I'm running Insight and Tk segfaults (which I what I want),
>> > but when I look at the stack all I see are "????" where I should
>> > see Tk functions.  I can set breakpoints in Tk functions (which don't
>> > work), I can browse Tk functions in the Function Browser, but can't
>> > see them in drop down comboboxes in the Source Window.
>> >
>> > It seems to me that this is and intermittent problem with Insight.
>> > I checked it against at pre-Tcl8.3 Insight build and could see
>> > all the stack entries without any problem.
>> >
>> 
>> This is a common symptom of stack corruption as well.  What does the
>> command like "bt" command shows?  (try it in the console window,
>> I don't think it matters not being in the real console).
>
>bt shows the same as the Insight stack window, i.e. stack
>frames inside the Tk DLL are shown as "??".  Running gdb
>using the "-nw" flags gives the same results.
>
>If it is stack corruption, would it be normal to vary between
>similar versions of gdb?

I just checked in some more changes that deal with DLL loading.
I don't know if they will fix your problem or not.

However, if they don't, I suspect that the "dll" command will
properly load the symbols for the DLL, assuming that there
are symbols in the DLL.

cgf

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Fernando Nasser]

Ian Roxborough wrote:
> 
> bt shows the same as the Insight stack window, i.e. stack
> frames inside 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

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Ian Roxborough]

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

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Keith Seitz]

On Thu, 1 Nov 2001, Ian Roxborough wrote:

> 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.

Didn't we ascertain last time that gdb was messed up w.r.t. dlls? See the
"FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]" thread.

Keith

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Christopher Faylor]

On Thu, Nov 01, 2001 at 12:48:29PM -0800, Keith Seitz wrote:
>On Thu, 1 Nov 2001, Ian Roxborough wrote:
>
>> 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.
>
>Didn't we ascertain last time that gdb was messed up w.r.t. dlls? See the
>"FYI: DLL breakpoint bug [was: Re: DLLs and Insight...]" thread.

If gdb is messed up wrt DLLs then I wouldn't be able to use it to debug
cygwin.

I've been checking in fixes for the last few weeks for dll handling.

From the description, it really sounds like there are two different versions
of the DLL on the system and either GDB or tcl has found the wrong one.

I previously suggested using the 'dll' command to load symbols.  'info shared'
will also show the list of loaded dlls.

cgf

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Ian Roxborough]

Christopher Faylor wrote:
> I've been checking in fixes for the last few weeks for dll handling.

I've been keeping my gdb up-to-date for that reason.
 
> From the description, it really sounds like there are two different versions
> of the DLL on the system and either GDB or tcl has found the wrong one.

I'm pretty sure that the right DLLs are being used.
The 'info shared' command also seems to show the correct DLLs.

> I previously suggested using the 'dll' command to load symbols.  'info shared'
> will also show the list of loaded dlls.

Using the 'dll' command to load the dlls didn't really change anything.

Ian.

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Keith Seitz]

Well, I've got a recent cygwin (1.3.4 DLL checked out yesterday) and a
relatively recent gdb (also from yesterday).

I run gdb on itself and I set a break at Tcl_Realloc. The stack is
immediately wrong. The SrcWin shows the right place, but the StackWin and
gdb show the wrong place:

(gdb) bt
#0  Tcl_Realloc (
    ptr=0x2679a0 "C:/cygwin/home/keiths/sources/gdb/built/H-i686-pc-cygwin/share
/tcl8.3 C:/cygwin/home/keiths/sources/gdb/built/H-i686-pc-cygwin/share/tcl8.3 C:
/cygwin/home/keiths/sources/gdb/built/share/tcl8.3 C:/cygw"..., size=800)
    at ../../../src/tcl/win/../generic/tclCkalloc.c:897
#1  0x10058d09 in Tcl_DStringSetLength (dsPtr=0x22f644, length=799)
    at ../../../src/tcl/win/../generic/tclUtil.c:1651
#2  0x10026a95 in DestroyButton ()
    at ../../../src/tcl/win/../generic/tclEncoding.c:986
#3  0x10028314 in ComputeArcBbox ()
    at ../../../src/tcl/win/../generic/tclEncoding.c:2744
#4  0x10026c0b in ConfigureButton ()
    at ../../../src/tcl/win/../generic/tclEncoding.c:1131
#5  0x005021b5 in gdbtk_init (
    argv0=0x22fd78 "/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/gdb")
    at ../../src/gdb/gdbtk/generic/gdbtk.c:379
#6  0x00405783 in gdb_init (
    argv0=0x22fd78 "/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/gdb")
    at ../../src/gdb/top.c:2055
#7  0x00401a35 in captured_main (data=0x22fd4c) at ../../src/gdb/main.c:460
#8  0x00402ae4 in do_catch_errors (uiout=0x5b0668, data=0x22fd0c)
    at ../../src/gdb/top.c:488
#9  0x0040294f in catcher (func=0x402ad0 <do_catch_errors>,
    func_uiout=0x5b0668, func_args=0x22fd0c, func_val=0x22fd04,
---Type <return> to continue, or q <return> to quit---
    func_caught=0x22fd08, errstring=0x4011a6 "", mask=6)
    at ../../src/gdb/top.c:420
#10 0x00402b23 in catch_errors (func=0x401350 <captured_main>,
    func_args=0x22fd4c, errstring=0x4011a6 "", mask=6)
    at ../../src/gdb/top.c:500
#11 0x00401fae in main (argc=1, argv=0x10281568) at ../../src/gdb/main.c:702
#12 0x61003f82 in dll_crt0_1 () at ../../../../src/winsup/cygwin/dcrt0.cc:769
#13 0x61004199 in _dll_crt0 () at ../../../../src/winsup/cygwin/dcrt0.cc:850
#14 0x610041d8 in dll_crt0 (uptr=0x0)
    at ../../../../src/winsup/cygwin/dcrt0.cc:862
#15 0x005ae0d3 in cygwin_crt0 ()
    at /cygnus/netrel/src/cygwin-1.3.3-2/winsup/cygwin/lib/cygwin_crt0.c:33

You can see right here that frame #2 is wrong. It should be:

(gdb) tk gdb_loc
../../../src/tcl/win/../generic/tclEncoding.c Tcl_UtfToExternalString /home/keiths/sources/gdb/net/tcl/win/../../../src/tcl/win/../generic/tclEncoding.c 986 0x10026a95 0x10010f68 {}

(gdb) p/x $pc
$1 = 0x10026a95
(gdb) info symbol 0x10026a95
DestroyButton + 173 in section .text
DestroyButton + 173 in section .text
(gdb) disas
Dump of assembler code for function DestroyButton:
0x100269e8 <DestroyButton>:           movl   $0x3,0xffffffec(%ebp)
...
0x10026b41 <Tcl_FindExecutable+81>:   lea    0xffffff20(%ebp),%esi
(gdb) disas Tcl_UtfToExternalDString
Dump of assembler code for function Tcl_UtfToExternalDString:
0x10026948 <Tcl_UtfToExternalDString>: push %ebp
...
0x100269e5 <Tcl_UtfToExternalDString+157>: lea  0xfffffff0(%ebp),%eax
0x100269e8 <DestroyButton>:            movl    $0x3,0xffffffec(%ebp)
...
0x10026ab1 <DestroyButton+201>:        ret
(gdb)

As you can see, the output is really messed up. The PC is clearly in
Tcl_UtfToExternalDString, yet gdb claims it is in DestroyButton.
Additionally gdb disassembles more than it should.

(gdb) info shared
/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/cygtcl83.dll      10001000
/usr/bin/cygwin1.dll                                                  61001000
/cygdrive/c/WINNT/system32/kernel32.dll                               77e81000
/cygdrive/c/WINNT/system32/advapi32.dll                               77db1000
/cygdrive/c/WINNT/system32/rpcrt4.dll                                 77d41000
/cygdrive/c/WINNT/system32/user32.dll                                 77e11000
/cygdrive/c/WINNT/system32/gdi32.dll                                  77f41000
/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/cygtix4183.dll    66601000
/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/cygtk83.dll       00b11000
/cygdrive/c/WINNT/system32/comdlg32.dll                               76b31000
/cygdrive/c/WINNT/system32/shlwapi.dll                                70bd1000
/cygdrive/c/WINNT/system32/msvcrt.dll                                 78001000
/cygdrive/c/WINNT/system32/comctl32.dll                               71781000
/cygdrive/c/WINNT/system32/shell32.dll                                782f1000
/cygdrive/c/WINNT/system32/psapi.dll                                  690a1000

[Is msvcrt.dll allowed???]

If I have time to look at this, I will report my findings.
Keith

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Christopher Faylor]

On Thu, Nov 01, 2001 at 02:05:26PM -0800, Keith Seitz wrote:
>
>Well, I've got a recent cygwin (1.3.4 DLL checked out yesterday) and a
>relatively recent gdb (also from yesterday).
>
>I run gdb on itself and I set a break at Tcl_Realloc. The stack is
>immediately wrong. The SrcWin shows the right place, but the StackWin and
>gdb show the wrong place:
>
>(gdb) bt
>#0  Tcl_Realloc (
>    ptr=0x2679a0 "C:/cygwin/home/keiths/sources/gdb/built/H-i686-pc-cygwin/share
>/tcl8.3 C:/cygwin/home/keiths/sources/gdb/built/H-i686-pc-cygwin/share/tcl8.3 C:
>/cygwin/home/keiths/sources/gdb/built/share/tcl8.3 C:/cygw"..., size=800)
>    at ../../../src/tcl/win/../generic/tclCkalloc.c:897
>#1  0x10058d09 in Tcl_DStringSetLength (dsPtr=0x22f644, length=799)
>    at ../../../src/tcl/win/../generic/tclUtil.c:1651
>#2  0x10026a95 in DestroyButton ()
>    at ../../../src/tcl/win/../generic/tclEncoding.c:986
>#3  0x10028314 in ComputeArcBbox ()
>    at ../../../src/tcl/win/../generic/tclEncoding.c:2744
>#4  0x10026c0b in ConfigureButton ()
>    at ../../../src/tcl/win/../generic/tclEncoding.c:1131
>#5  0x005021b5 in gdbtk_init (
>    argv0=0x22fd78 "/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/gdb")
>    at ../../src/gdb/gdbtk/generic/gdbtk.c:379
>#6  0x00405783 in gdb_init (
>    argv0=0x22fd78 "/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/gdb")
>    at ../../src/gdb/top.c:2055
>#7  0x00401a35 in captured_main (data=0x22fd4c) at ../../src/gdb/main.c:460
>#8  0x00402ae4 in do_catch_errors (uiout=0x5b0668, data=0x22fd0c)
>    at ../../src/gdb/top.c:488
>#9  0x0040294f in catcher (func=0x402ad0 <do_catch_errors>,
>    func_uiout=0x5b0668, func_args=0x22fd0c, func_val=0x22fd04,
>---Type <return> to continue, or q <return> to quit---
>    func_caught=0x22fd08, errstring=0x4011a6 "", mask=6)
>    at ../../src/gdb/top.c:420
>#10 0x00402b23 in catch_errors (func=0x401350 <captured_main>,
>    func_args=0x22fd4c, errstring=0x4011a6 "", mask=6)
>    at ../../src/gdb/top.c:500
>#11 0x00401fae in main (argc=1, argv=0x10281568) at ../../src/gdb/main.c:702
>#12 0x61003f82 in dll_crt0_1 () at ../../../../src/winsup/cygwin/dcrt0.cc:769
>#13 0x61004199 in _dll_crt0 () at ../../../../src/winsup/cygwin/dcrt0.cc:850
>#14 0x610041d8 in dll_crt0 (uptr=0x0)
>    at ../../../../src/winsup/cygwin/dcrt0.cc:862
>#15 0x005ae0d3 in cygwin_crt0 ()
>    at /cygnus/netrel/src/cygwin-1.3.3-2/winsup/cygwin/lib/cygwin_crt0.c:33
>
>You can see right here that frame #2 is wrong. It should be:
>
>(gdb) tk gdb_loc
>../../../src/tcl/win/../generic/tclEncoding.c Tcl_UtfToExternalString /home/keiths/sources/gdb/net/tcl/win/../../../src/tcl/win/../generic/tclEncoding.c 986 0x10026a95 0x10010f68 {}
>
>(gdb) p/x $pc
>$1 = 0x10026a95
>(gdb) info symbol 0x10026a95
>DestroyButton + 173 in section .text
>DestroyButton + 173 in section .text
>(gdb) disas
>Dump of assembler code for function DestroyButton:
>0x100269e8 <DestroyButton>:           movl   $0x3,0xffffffec(%ebp)
>...
>0x10026b41 <Tcl_FindExecutable+81>:   lea    0xffffff20(%ebp),%esi
>(gdb) disas Tcl_UtfToExternalDString
>Dump of assembler code for function Tcl_UtfToExternalDString:
>0x10026948 <Tcl_UtfToExternalDString>: push %ebp
>...
>0x100269e5 <Tcl_UtfToExternalDString+157>: lea  0xfffffff0(%ebp),%eax
>0x100269e8 <DestroyButton>:            movl    $0x3,0xffffffec(%ebp)
>...
>0x10026ab1 <DestroyButton+201>:        ret
>(gdb)
>
>As you can see, the output is really messed up. The PC is clearly in
>Tcl_UtfToExternalDString, yet gdb claims it is in DestroyButton.
>Additionally gdb disassembles more than it should.

Everybody is building without optimization, right?  Otherwise I wouldn't
be surprised to hear that there could be screwed up.

It there an -fomit-frame-pointer in there somewhere by any chance?

Also, sorry to ask such a basic question but did you step a few lines
into Tcl_Realloc and check the back trace again?

Final question:  What does the latest cygwin release version of gdb
show?

>(gdb) info shared
>/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/cygtcl83.dll      10001000
>/usr/bin/cygwin1.dll                                                  61001000
>/cygdrive/c/WINNT/system32/kernel32.dll                               77e81000
>/cygdrive/c/WINNT/system32/advapi32.dll                               77db1000
>/cygdrive/c/WINNT/system32/rpcrt4.dll                                 77d41000
>/cygdrive/c/WINNT/system32/user32.dll                                 77e11000
>/cygdrive/c/WINNT/system32/gdi32.dll                                  77f41000
>/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/cygtix4183.dll    66601000
>/home/keiths/sources/gdb/built/H-i686-pc-cygwin/bin/cygtk83.dll       00b11000
>/cygdrive/c/WINNT/system32/comdlg32.dll                               76b31000
>/cygdrive/c/WINNT/system32/shlwapi.dll                                70bd1000
>/cygdrive/c/WINNT/system32/msvcrt.dll                                 78001000
>/cygdrive/c/WINNT/system32/comctl32.dll                               71781000
>/cygdrive/c/WINNT/system32/shell32.dll                                782f1000
>/cygdrive/c/WINNT/system32/psapi.dll                                  690a1000
>
>[Is msvcrt.dll allowed???]

Nope.  I wonder what's loading msvcrt.dll.

cgf

Re: Stack Window Problem [was: Re: DLLs and Insight...]

[Keith Seitz]

On Thu, 1 Nov 2001, Christopher Faylor wrote:

> Everybody is building without optimization, right?  Otherwise I wouldn't
> be surprised to hear that there could be screwed up.

Doh! I was _certain_ that I'd built without optimization. Being paranoid
now, I rebuilt tcl, tk, itcl, tix, and gdb. Backtraces are sane again.

> It there an -fomit-frame-pointer in there somewhere by any chance?

No.

> Final question:  What does the latest cygwin release version of gdb
> show?

For Ian's crash (open/dismiss global preferences, change application
focus), I get exactly the same output (now) with cygwin's gdb and the CVS
gdb. Sheesh. At least that little bit of stupidity is cleared up...

> >/cygdrive/c/WINNT/system32/msvcrt.dll                                 78001000
> >
> >[Is msvcrt.dll allowed???]
>
> Nope.  I wonder what's loading msvcrt.dll.

Hmmm. Still there. I tried running tclsh, wish, etc under gdb. "info
shared" shows msvcrt.dll showing up in wish83.exe.

Keith