2 Segfaults in Insights (Latest CVS)

2 Segfaults in Insights (Latest CVS)

[Steven Johnson]

I am experiencing 2 Segfaults in Insight. 1 I have tracked a cause for, the
other I havent. Before I get into details I will spout the preliminaries.

Host: Mandrake Linux 7.0 (Kernel 2.2.14)
Insight Version: CVS as of today.
configuration: ../src/configure --target=powerpc-eabi 
                                --program-prefix=insight-ppc
                                --prefix=/opt/powerpc-gdb

GCC Version: 2.95.2

Details:
Segfault 1: 

Start Insight     : OK
Connect to Target : OK
Download          : Segfault.

I am starting insight with
/opt/powerpc-gdb/bin/insight-ppc-gdb                    
                                    --command=mpc860-gdb-init

The command file defines some hooks so I can operate my target hardware
properly. Especially with regard to loading the program (I am running out of
flash!).

When I connect (using the standard dialog). I am connecting to a server for my
BDM Interface to the PowerPC MPC860 Board. It is running on the same computer
as Insight, and it communicates using the standard GDB Remote protocol. I
Connect to localhost:2345. 

When I choose download Insight almost immediately segfaults in "gdbtypes.c,
line 1060" This is not the problem however, it is the symptom. A Stack trace
gives me a trace through values.c, valops.c, eval.c and eventually to the
function set_command in printcmd.c (line 1041).

This works fine if I start gdb with the --nw option BTW.

What I "think" the problem is:

Insight appears to hook all "set" operations when it is executing a gui command
such as download. It does this, so that any variables that are changed by the
command are updated on the display. My script adds a hook to the load
operation. The hook writes to a register with:

set $ictrl=0x7

I need this because of peculiarities with the way I need to operate my
hardware. Insight executes this command on the target properly. It then
interprets the SET operation. Looks up symbol $ictrl (which doesn't exist, its
a register not a symbol of the program.) tries to set it's local value to 0x7
and segfaults because the pointer to the symbol is invalid crap. GDB without
Insight doesn't do it because it does not post interpret the set operations.

set_command is the culprit that does this. I have tested my hypothesis by
commenting out the expression evaluation in set_command. When I do this,
loading works fine. This is obviously not the correct fix. I can see what
Insight is attempting to achieve and it is valid. Im not sure how to fix the
case where the symbol doesn't exist. Any input would be appreciated as I would
really like to get this fixed.

I think it could be forced on any Insight by creating a hook on load that
updates a register to some arbitrary value. For example:

define hook-load
  set $eax=0x01
  set $eax=0x00
end

I did it twice to defeat the register caching mechanism for the purposes of the
test. (If the first write doesn't do anything, the second will.) I believe this
will segfault Insight everytime (NOTE: I haven't tested this on an intel target
myself)

The second segfault is currently not giving me much information at all:
Program received SIGSEGV,segmentation fault.
0x7d68375 in ?? ()
(gdb) info stack
#0 0x7d68375 in ?? ()
Cannot access memory address 0x6f74746e
(gdb)

This occurs when I set a breakpoint, run to it, and then try and clear it. (I
need to do more testing.) I have mentioned it to see if it is already known, or
unique to me.

Anyway, any comments on this stuff?

Steven Johnson

Re: 2 Segfaults in Insights (Latest CVS)

[Fernando Nasser]

Steve,

We have a bug tracking database on the Insight web page
   http://sources.redhat.com/insight
You can use that to report bugs and make sure thay are not missed or forgotten
(well, this was not true before, but I will try to make sure now it is).
You still have to follow a few links for now (until we improve the page a bit).

W.r.t. your two problems here (which I have never seem before), lets talk about
the first as there is not much information about the second one yet.  here it goes:


Steven Johnson wrote:
> 
> When I choose download Insight almost immediately segfaults in "gdbtypes.c,
> line 1060" This is not the problem however, it is the symptom. A Stack trace
> gives me a trace through values.c, valops.c, eval.c and eventually to the
> function set_command in printcmd.c (line 1041).
> 
I would need to see this stack trace.  Can you post it please?


> This works fine if I start gdb with the --nw option BTW.
> 
This do point to a GUI problem or an interaction between the GUI and gdb.


> What I "think" the problem is:
> 
> Insight appears to hook all "set" operations when it is executing a gui command
> such as download. It does this, so that any variables that are changed by the
> command are updated on the display. My script adds a hook to the load
> operation. The hook writes to a register with:
> 
> set $ictrl=0x7
> 
Your are being too optimistic :-)  Insight is not that aware of things that are
done in the simulated console or even in the scripts (as they are still gdb scripts,
not insight scripts as we may have in the future).


> I need this because of peculiarities with the way I need to operate my
> hardware. Insight executes this command on the target properly. It then
> interprets the SET operation. Looks up symbol $ictrl (which doesn't exist, its
> a register not a symbol of the program.) tries to set it's local value to 0x7
> and segfaults because the pointer to the symbol is invalid crap. GDB without
> Insight doesn't do it because it does not post interpret the set operations.
> 
You are right that the problem has something to do with your set command, but the
GUI set command hook handlers do nothing of a sort.  I does grab data from the
command struct so it is possible that it could be fouled by some bad data in there.

But I would need to look at that stack and at the contents of the cmd_list_struct
that is passed back by gdb to the GUI in the hook callback.



> set_command is the culprit that does this. I have tested my hypothesis by
> commenting out the expression evaluation in set_command. When I do this,
> loading works fine. This is obviously not the correct fix. I can see what
> Insight is attempting to achieve and it is valid. Im not sure how to fix the
> case where the symbol doesn't exist. Any input would be appreciated as I would
> really like to get this fixed.
> 
> I think it could be forced on any Insight by creating a hook on load that
> updates a register to some arbitrary value. For example:
> 
> define hook-load
>   set $eax=0x01
>   set $eax=0x00
> end
> 
> I did it twice to defeat the register caching mechanism for the purposes of the
> test. (If the first write doesn't do anything, the second will.) I believe this
> will segfault Insight everytime (NOTE: I haven't tested this on an intel target
> myself)
> 

I will try that.  Thanks.



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

Re: 2 Segfaults in Insights (Latest CVS)

[Steven Johnson]

Fernando Nasser wrote:
> 
> Steve,
> 
> We have a bug tracking database on the Insight web page
>    http://sources.redhat.com/insight
Just did that. :)

> I would need to see this stack trace.  Can you post it please?
> 

Here tis.

GNU gdb 19991116
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux".

Program received signal SIGSEGV, Segmentation fault.
0x4018915c in memcpy () from /lib/libc.so.6
#0  0x4018915c in memcpy () from /lib/libc.so.6
#1  0x891b4f8 in ?? ()
#2  0x80a5372 in value_assign (toval=0x891b4f8, fromval=0x89bdc50) at ../../src/gdb/valops.c:811
#3  0x80a275a in evaluate_subexp_standard (expect_type=0x0, exp=0x89b8d90, pos=0xbfffc658, 
    noside=EVAL_NORMAL) at ../../src/gdb/eval.c:1150
#4  0x80a053f in evaluate_subexp (expect_type=0x0, exp=0x89b8d90, pos=0xbfffc658, noside=EVAL_NORMAL)
    at ../../src/gdb/eval.c:71
#5  0x80a06c6 in evaluate_expression (exp=0x89b8d90) at ../../src/gdb/eval.c:145
#6  0x80ae8dc in set_command (exp=0x89dd87c "$ictrl=0x7", from_tty=0)
    at ../../src/gdb/printcmd.c:1041
#7  0x80e2c9a in gdbtk_call_command (cmdblk=0x84ce898, arg=0x89dd87c "$ictrl=0x7", from_tty=0)
    at ../../src/gdb/gdbtk/generic/gdbtk-hooks.c:519
#8  0x80fec23 in execute_command (p=0x89dd885 "7", from_tty=0) at ../../src/gdb/top.c:1521
#9  0x80fe3a5 in execute_control_command (cmd=0x8541188) at ../../src/gdb/top.c:1085
#10 0x80fe9af in execute_user_command (c=0x84c9300, args=0x0) at ../../src/gdb/top.c:1437
#11 0x80febcf in execute_command (p=0x89d5e0b "", from_tty=0) at ../../src/gdb/top.c:1515
#12 0x80fe3a5 in execute_control_command (cmd=0x8694710) at ../../src/gdb/top.c:1085
#13 0x80fe9af in execute_user_command (c=0x85cb398, args=0x0) at ../../src/gdb/top.c:1437
#14 0x80feba0 in execute_command (p=0x89afc3a "e", from_tty=0) at ../../src/gdb/top.c:1507
#15 0x80dd931 in gdb_cmd (clientData=0x80dd850, interp=0x84e06c0, objc=2, objv=0x84e136c)
    at ../../src/gdb/gdbtk/generic/gdbtk-cmds.c:830
#16 0x80dd593 in wrapped_call (opaque_args=0xbfffc9c8)
    at ../../src/gdb/gdbtk/generic/gdbtk-cmds.c:536
#17 0x80fddfc in catch_errors (func=0x80dd578 <wrapped_call>, args=0xbfffc9c8, 
    errstring=0x83c34c3 "", mask=6) at ../../src/gdb/top.c:607
#18 0x80dd4b6 in call_wrapper (clientData=0x80dd850, interp=0x84e06c0, objc=2, objv=0x84e136c)
    at ../../src/gdb/gdbtk/generic/gdbtk-cmds.c:474
#19 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89afee0)
    at ../../../src/tcl/unix/../generic/tclExecute.c:955
#20 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x85ed220)
    at ../../../src/tcl/unix/../generic/tclBasic.c:2645
#21 0x82c8290 in Itcl_EvalMemberCode (interp=0x84e06c0, mfunc=0x89891a8, member=0x89891c0, 
    contextObj=0x0, objc=1, objv=0x84e1368)
    at /home/steven/dev/tools/gdb/src/itcl/itcl/generic/itcl_methods.c:1029
#22 0x82c8c6f in Itcl_ExecProc (clientData=0x89891a8, interp=0x84e06c0, objc=1, objv=0x84e1368)
    at /home/steven/dev/tools/gdb/src/itcl/itcl/generic/itcl_methods.c:1605
#23 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89b54f8)
    at ../../../src/tcl/unix/../generic/tclExecute.c:955
#24 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x898d850)
    at ../../../src/tcl/unix/../generic/tclBasic.c:2645
#25 0x8395b1c in Tcl_UplevelObjCmd (dummy=0x0, interp=0x84e06c0, objc=3, objv=0x84e135c)
    at ../../../src/tcl/unix/../generic/tclProc.c:609
#26 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x8530d68)
    at ../../../src/tcl/unix/../generic/tclExecute.c:955
#27 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x84f9de0)
    at ../../../src/tcl/unix/../generic/tclBasic.c:2645
#28 0x839605a in TclObjInterpProc (clientData=0x85046d0, interp=0x84e06c0, objc=2, objv=0x84e1354)
    at ../../../src/tcl/unix/../generic/tclProc.c:996
#29 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x8991f18)
    at ../../../src/tcl/unix/../generic/tclExecute.c:955
#30 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x868f2a8)
    at ../../../src/tcl/unix/../generic/tclBasic.c:2645
#31 0x835f06b in Tcl_Eval (interp=0x84e06c0, string=0xbfffe024 "Download::download_it")
    at ../../../src/tcl/unix/../generic/tclBasic.c:2453
#32 0x83607fa in Tcl_GlobalEval (interp=0x84e06c0, command=0xbfffe024 "Download::download_it")
    at ../../../src/tcl/unix/../generic/tclBasic.c:3983
#33 0x8350700 in TkCopyAndGlobalEval (interp=0x84e06c0, script=0x8871ef8 "Download::download_it")
    at ../../../src/tk/unix/../generic/tkBind.c:4547
#34 0x831c76f in TkInvokeMenu (interp=0x84e06c0, menuPtr=0x886aa68, index=1)
    at ../../../src/tk/unix/../generic/tkMenu.c:922
#35 0x831c2b1 in MenuWidgetCmd (clientData=0x886aa68, interp=0x84e06c0, argc=3, argv=0xbfffe27c)
    at ../../../src/tk/unix/../generic/tkMenu.c:749
#36 0x835e995 in TclInvokeStringCommand (clientData=0x886d868, interp=0x84e06c0, objc=3, 
    objv=0x84e1348) at ../../../src/tcl/unix/../generic/tclBasic.c:1745
#37 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89c2438)
    at ../../../src/tcl/unix/../generic/tclExecute.c:955
#38 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x89e2040)
    at ../../../src/tcl/unix/../generic/tclBasic.c:2645
#39 0x8395b1c in Tcl_UplevelObjCmd (dummy=0x0, interp=0x84e06c0, objc=3, objv=0x84e133c)
    at ../../../src/tcl/unix/../generic/tclProc.c:609
#40 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89939f0)
    at ../../../src/tcl/unix/../generic/tclExecute.c:955
#41 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x8506ec8)
    at ../../../src/tcl/unix/../generic/tclBasic.c:2645
#42 0x839605a in TclObjInterpProc (clientData=0x851bd70, interp=0x84e06c0, objc=3, objv=0x84e1330)
    at ../../../src/tcl/unix/../generic/tclProc.c:996
#43 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x899b5d8)
    at ../../../src/tcl/unix/../generic/tclExecute.c:955
#44 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x85c4858)
    at ../../../src/tcl/unix/../generic/tclBasic.c:2645
#45 0x835f06b in Tcl_Eval (interp=0x84e06c0, 
    string=0x8991fa8 "\n   tkMenuInvoke .srcwin0.#srcwin0#srcwin#container#pane0#childsite#con#m.#srcwin0#srcwin#container#pane0#childsite#con#m#run 1\n")
    at ../../../src/tcl/unix/../generic/tclBasic.c:2453
#46 0x83607fa in Tcl_GlobalEval (interp=0x84e06c0, 
    command=0x8991fa8 "\n   tkMenuInvoke .srcwin0.#srcwin0#srcwin#container#pane0#childsite#con#m.#srcwin0#srcwin#container#pane0#childsite#con#m#run 1\n")
    at ../../../src/tcl/unix/../generic/tclBasic.c:3983
#47 0x834d730 in Tk_BindEvent (bindingTable=0x84f4a38, eventPtr=0x89c6a40, tkwin=0x886a898, 
    numObjects=0, objectPtr=0xbffff49c) at ../../../src/tk/unix/../generic/tkBind.c:1731
#48 0x835137a in TkBindEventProc (winPtr=0x886a898, eventPtr=0x89c6a40)
    at ../../../src/tk/unix/../generic/tkCmds.c:242
#49 0x82fe5e0 in Tk_HandleEvent (eventPtr=0x89c6a40) at ../../../src/tk/unix/../generic/tkEvent.c:657
#50 0x82fe8aa in WindowEventProc (evPtr=0x89c6a38, flags=-3)
    at ../../../src/tk/unix/../generic/tkEvent.c:983
#51 0x838fdf7 in Tcl_ServiceEvent (flags=-3) at ../../../src/tcl/unix/../generic/tclNotify.c:444
#52 0x83900d1 in Tcl_DoOneEvent (flags=0) at ../../../src/tcl/unix/../generic/tclNotify.c:683
#53 0x82fe912 in Tk_MainLoop () at ../../../src/tk/unix/../generic/tkEvent.c:1041
#54 0x80e2a66 in tk_command_loop () at ../../src/gdb/gdbtk/generic/gdbtk-hooks.c:383
#55 0x809ba68 in captured_command_loop (data=0x0) at ../../src/gdb/main.c:104
#56 0x80fddfc in catch_errors (func=0x809ba50 <captured_command_loop>, args=0x0, 
    errstring=0x83a3c62 "", mask=6) at ../../src/gdb/top.c:607
#57 0x809c523 in captured_main (data=0xbffff914) at ../../src/gdb/main.c:749
#58 0x80fddfc in catch_errors (func=0x809ba9c <captured_main>, args=0xbffff914, 
    errstring=0x83a3c62 "", mask=6) at ../../src/gdb/top.c:607
#59 0x809c54f in main (argc=2, argv=0xbffff984) at ../../src/gdb/main.c:761


> >
> Your are being too optimistic :-)  Insight is not that aware of things that are
> done in the simulated console or even in the scripts (as they are still gdb scripts,
> not insight scripts as we may have in the future).
>

I appreciate this, what I believed was happening is Insight itself would "set" when it wanted to update something. And that the hook was for the purpose of a general catch all of Insights "set"
operations. (im sure i saw a comment to this effect somewhere) Insight definately calls the set_command operation, and is executing it "After" the set command has been successfully performed on the
target. If I comment out the body of set_command, problem goes away. But im not sure what else i am breaking. The normal do_setshow_command operation does not appear to call set_command. What is
set_command in printcmd.c actually providing??
 
> But I would need to look at that stack and at the contents of the cmd_list_struct
> that is passed back by gdb to the GUI in the hook callback.
>

How do I get this for you? (What commands.)
 
Is there a way of getting GDB (Normal command line) to log its session? I can't find it if there is.

Steven Johnson

Re: 2 Segfaults in Insights (Latest CVS)

[Fernando Nasser]

Steven,

This does not seem to be a GUI bug.  Maybe the way things are being used by the GUI and
your script create the appropriate scenario for this to happen, but there is not much
that the GUI could do to influence the particular code that is executing. 


As we can see from the stack, the set command was called with a valid argument
(frame #6, exp=0x89dd87c "$ictrl=0x7").  It is following it's normal course of execution,
calling evaluate_expression(), which goes through evaluate_subexp() to
evaluate_subexp_standard().  Noticing that it is an "assign" (because there are two
arguments separated by an "="), it calls value assign.

If I could I would do an "up 2" and print *toval and *fromval.  But if everything is OK
toval must be an lval_register and value_assign will go through some register
reading/writting depending on the register type.

At the end, a value of the same type as the register is created, filled with the 
new value and returned.  The core dump happens when the copy of the register is
being filled.

      memcpy (VALUE_CONTENTS_ALL_RAW (val), VALUE_CONTENTS_ALL_RAW (arg),
              TYPE_LENGTH (VALUE_ENCLOSING_TYPE (arg)));

Either VALUE_CONTENTS_ALL_RAW (val) or VALUE_CONTENTS_ALL_RAW (arg) or
TYPE_LENGTH (VALUE_ENCLOSING_TYPE (arg)) is screwed or...

Your stack frame #1 looks strange.  You should see value_copy () in there.
If we are facing some kind of stack corruption then we can just forget all
the above analysis.

Bottom line: unless I can reproduce it here it will be very hard for me to track
it down.  I don't have a powerPC though.

P.S: Your PR says: "The segfault occurs at line 1060 in gdbtypes.c"
     Is the core dump location constant?  If not, the stack corruption hypothesis
     is reinforced :-(


Steven Johnson wrote:
> 
> Here tis.
> 
> GNU gdb 19991116
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i586-mandrake-linux".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x4018915c in memcpy () from /lib/libc.so.6
> #0  0x4018915c in memcpy () from /lib/libc.so.6
> #1  0x891b4f8 in ?? ()
> #2  0x80a5372 in value_assign (toval=0x891b4f8, fromval=0x89bdc50) at ../../src/gdb/valops.c:811
> #3  0x80a275a in evaluate_subexp_standard (expect_type=0x0, exp=0x89b8d90, pos=0xbfffc658,
>     noside=EVAL_NORMAL) at ../../src/gdb/eval.c:1150
> #4  0x80a053f in evaluate_subexp (expect_type=0x0, exp=0x89b8d90, pos=0xbfffc658, noside=EVAL_NORMAL)
>     at ../../src/gdb/eval.c:71
> #5  0x80a06c6 in evaluate_expression (exp=0x89b8d90) at ../../src/gdb/eval.c:145
> #6  0x80ae8dc in set_command (exp=0x89dd87c "$ictrl=0x7", from_tty=0)
>     at ../../src/gdb/printcmd.c:1041
> #7  0x80e2c9a in gdbtk_call_command (cmdblk=0x84ce898, arg=0x89dd87c "$ictrl=0x7", from_tty=0)
>     at ../../src/gdb/gdbtk/generic/gdbtk-hooks.c:519
> #8  0x80fec23 in execute_command (p=0x89dd885 "7", from_tty=0) at ../../src/gdb/top.c:1521
> #9  0x80fe3a5 in execute_control_command (cmd=0x8541188) at ../../src/gdb/top.c:1085
> #10 0x80fe9af in execute_user_command (c=0x84c9300, args=0x0) at ../../src/gdb/top.c:1437
> #11 0x80febcf in execute_command (p=0x89d5e0b "", from_tty=0) at ../../src/gdb/top.c:1515
> #12 0x80fe3a5 in execute_control_command (cmd=0x8694710) at ../../src/gdb/top.c:1085
> #13 0x80fe9af in execute_user_command (c=0x85cb398, args=0x0) at ../../src/gdb/top.c:1437
> #14 0x80feba0 in execute_command (p=0x89afc3a "e", from_tty=0) at ../../src/gdb/top.c:1507
> #15 0x80dd931 in gdb_cmd (clientData=0x80dd850, interp=0x84e06c0, objc=2, objv=0x84e136c)
>     at ../../src/gdb/gdbtk/generic/gdbtk-cmds.c:830
> #16 0x80dd593 in wrapped_call (opaque_args=0xbfffc9c8)
>     at ../../src/gdb/gdbtk/generic/gdbtk-cmds.c:536
> #17 0x80fddfc in catch_errors (func=0x80dd578 <wrapped_call>, args=0xbfffc9c8,
>     errstring=0x83c34c3 "", mask=6) at ../../src/gdb/top.c:607
> #18 0x80dd4b6 in call_wrapper (clientData=0x80dd850, interp=0x84e06c0, objc=2, objv=0x84e136c)
>     at ../../src/gdb/gdbtk/generic/gdbtk-cmds.c:474
> #19 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89afee0)
>     at ../../../src/tcl/unix/../generic/tclExecute.c:955
> #20 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x85ed220)
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2645
> #21 0x82c8290 in Itcl_EvalMemberCode (interp=0x84e06c0, mfunc=0x89891a8, member=0x89891c0,
>     contextObj=0x0, objc=1, objv=0x84e1368)
>     at /home/steven/dev/tools/gdb/src/itcl/itcl/generic/itcl_methods.c:1029
> #22 0x82c8c6f in Itcl_ExecProc (clientData=0x89891a8, interp=0x84e06c0, objc=1, objv=0x84e1368)
>     at /home/steven/dev/tools/gdb/src/itcl/itcl/generic/itcl_methods.c:1605
> #23 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89b54f8)
>     at ../../../src/tcl/unix/../generic/tclExecute.c:955
> #24 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x898d850)
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2645
> #25 0x8395b1c in Tcl_UplevelObjCmd (dummy=0x0, interp=0x84e06c0, objc=3, objv=0x84e135c)
>     at ../../../src/tcl/unix/../generic/tclProc.c:609
> #26 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x8530d68)
>     at ../../../src/tcl/unix/../generic/tclExecute.c:955
> #27 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x84f9de0)
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2645
> #28 0x839605a in TclObjInterpProc (clientData=0x85046d0, interp=0x84e06c0, objc=2, objv=0x84e1354)
>     at ../../../src/tcl/unix/../generic/tclProc.c:996
> #29 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x8991f18)
>     at ../../../src/tcl/unix/../generic/tclExecute.c:955
> #30 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x868f2a8)
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2645
> #31 0x835f06b in Tcl_Eval (interp=0x84e06c0, string=0xbfffe024 "Download::download_it")
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2453
> #32 0x83607fa in Tcl_GlobalEval (interp=0x84e06c0, command=0xbfffe024 "Download::download_it")
>     at ../../../src/tcl/unix/../generic/tclBasic.c:3983
> #33 0x8350700 in TkCopyAndGlobalEval (interp=0x84e06c0, script=0x8871ef8 "Download::download_it")
>     at ../../../src/tk/unix/../generic/tkBind.c:4547
> #34 0x831c76f in TkInvokeMenu (interp=0x84e06c0, menuPtr=0x886aa68, index=1)
>     at ../../../src/tk/unix/../generic/tkMenu.c:922
> #35 0x831c2b1 in MenuWidgetCmd (clientData=0x886aa68, interp=0x84e06c0, argc=3, argv=0xbfffe27c)
>     at ../../../src/tk/unix/../generic/tkMenu.c:749
> #36 0x835e995 in TclInvokeStringCommand (clientData=0x886d868, interp=0x84e06c0, objc=3,
>     objv=0x84e1348) at ../../../src/tcl/unix/../generic/tclBasic.c:1745
> #37 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89c2438)
>     at ../../../src/tcl/unix/../generic/tclExecute.c:955
> #38 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x89e2040)
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2645
> #39 0x8395b1c in Tcl_UplevelObjCmd (dummy=0x0, interp=0x84e06c0, objc=3, objv=0x84e133c)
>     at ../../../src/tcl/unix/../generic/tclProc.c:609
> #40 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x89939f0)
>     at ../../../src/tcl/unix/../generic/tclExecute.c:955
> #41 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x8506ec8)
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2645
> #42 0x839605a in TclObjInterpProc (clientData=0x851bd70, interp=0x84e06c0, objc=3, objv=0x84e1330)
>     at ../../../src/tcl/unix/../generic/tclProc.c:996
> #43 0x837847a in TclExecuteByteCode (interp=0x84e06c0, codePtr=0x899b5d8)
>     at ../../../src/tcl/unix/../generic/tclExecute.c:955
> #44 0x835f2a0 in Tcl_EvalObj (interp=0x84e06c0, objPtr=0x85c4858)
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2645
> #45 0x835f06b in Tcl_Eval (interp=0x84e06c0,
>     string=0x8991fa8 "\n   tkMenuInvoke .srcwin0.#srcwin0#srcwin#container#pane0#childsite#con#m.#srcwin0#srcwin#container#pane0#childsite#con#m#run 1\n")
>     at ../../../src/tcl/unix/../generic/tclBasic.c:2453
> #46 0x83607fa in Tcl_GlobalEval (interp=0x84e06c0,
>     command=0x8991fa8 "\n   tkMenuInvoke .srcwin0.#srcwin0#srcwin#container#pane0#childsite#con#m.#srcwin0#srcwin#container#pane0#childsite#con#m#run 1\n")
>     at ../../../src/tcl/unix/../generic/tclBasic.c:3983
> #47 0x834d730 in Tk_BindEvent (bindingTable=0x84f4a38, eventPtr=0x89c6a40, tkwin=0x886a898,
>     numObjects=0, objectPtr=0xbffff49c) at ../../../src/tk/unix/../generic/tkBind.c:1731
> #48 0x835137a in TkBindEventProc (winPtr=0x886a898, eventPtr=0x89c6a40)
>     at ../../../src/tk/unix/../generic/tkCmds.c:242
> #49 0x82fe5e0 in Tk_HandleEvent (eventPtr=0x89c6a40) at ../../../src/tk/unix/../generic/tkEvent.c:657
> #50 0x82fe8aa in WindowEventProc (evPtr=0x89c6a38, flags=-3)
>     at ../../../src/tk/unix/../generic/tkEvent.c:983
> #51 0x838fdf7 in Tcl_ServiceEvent (flags=-3) at ../../../src/tcl/unix/../generic/tclNotify.c:444
> #52 0x83900d1 in Tcl_DoOneEvent (flags=0) at ../../../src/tcl/unix/../generic/tclNotify.c:683
> #53 0x82fe912 in Tk_MainLoop () at ../../../src/tk/unix/../generic/tkEvent.c:1041
> #54 0x80e2a66 in tk_command_loop () at ../../src/gdb/gdbtk/generic/gdbtk-hooks.c:383
> #55 0x809ba68 in captured_command_loop (data=0x0) at ../../src/gdb/main.c:104
> #56 0x80fddfc in catch_errors (func=0x809ba50 <captured_command_loop>, args=0x0,
>     errstring=0x83a3c62 "", mask=6) at ../../src/gdb/top.c:607
> #57 0x809c523 in captured_main (data=0xbffff914) at ../../src/gdb/main.c:749
> #58 0x80fddfc in catch_errors (func=0x809ba9c <captured_main>, args=0xbffff914,
>     errstring=0x83a3c62 "", mask=6) at ../../src/gdb/top.c:607
> #59 0x809c54f in main (argc=2, argv=0xbffff984) at ../../src/gdb/main.c:761
> 
> > >
> > Your are being too optimistic :-)  Insight is not that aware of things that are
> > done in the simulated console or even in the scripts (as they are still gdb scripts,
> > not insight scripts as we may have in the future).
> >
> 
> I appreciate this, what I believed was happening is Insight itself would "set" when it wanted to update something. And that the hook was for the purpose of a general catch all of Insights "set"
> operations. (im sure i saw a comment to this effect somewhere) Insight definately calls the set_command operation, and is executing it "After" the set command has been successfully performed on the
> target. If I comment out the body of set_command, problem goes away. But im not sure what else i am breaking. The normal do_setshow_command operation does not appear to call set_command. What is
> set_command in printcmd.c actually providing??
> 
> > But I would need to look at that stack and at the contents of the cmd_list_struct
> > that is passed back by gdb to the GUI in the hook callback.
> >
> 
> How do I get this for you? (What commands.)
> 
> Is there a way of getting GDB (Normal command line) to log its session? I can't find it if there is.
> 
> Steven Johnson

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

Re: 2 Segfaults in Insights (Latest CVS)

[Fernando Nasser]

Steven Johnson wrote:
> 
> I think it could be forced on any Insight by creating a hook on load that
> updates a register to some arbitrary value. For example:
> 
> define hook-load
>   set $eax=0x01
>   set $eax=0x00
> end
> 

You know why?

Because the "after idle" event that is causing the damage was created when the first 
set command was completed.  As the GUI did not become idle the event was still there
and it happened to occur in the middle of the second register write operation
(from the second set).

Again, very nice detective work.  I thought tracking this down would be difficult
but with all the info you tracked down it will be a piece of cake :-)

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