Re: Crashes when "balloons" enabled

[gds <gds at chartertn dot net>]

Keith Seitz wrote:
> gds wrote:
>
> > They told me Insight has problems (paraphrasing!)
>
> I find that very amusing. I'm actually glad that they stop recommending 
> people use insight: I'm tired of being their support forum.
>
>
> > diff -c -r1.1 ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c
> > *** ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c      2007/07/14 
> > 18:33:59     1.1
> > --- ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c      2007/07/14 
> > 18:34:03
> > ***************
> > *** 599,606 ****
> >   static void
> >   install_variable (Tcl_Interp *interp, char *name)
> >   {
> > !   Tcl_CreateObjCommand (interp, name, variable_obj_command,
> > !                       NULL, NULL);
> >   }
> > --- 599,606 ----
> >   static void
> >   install_variable (Tcl_Interp *interp, char *name)
> >   {
> > !   Tcl_CreateObjCommand (interp, name, gdbtk_call_wrapper,
> > !                       (ClientData) variable_obj_command, NULL);
> >   }
>
> This patch should not be necessary: varobj should NEVER longjmp. It was 
> designed that way.

I tried it and for me all it did was disable ballooning. So I backed it out.

> BTW, all those other patches are against GDB, not insight. I'm afraid I 
> still don't understand what your procedure for producing this bug is. 
> Can you restate it, AND BE CONCISE. (ie., 1. Load this, 2. click this, 
> 3. click that). The more detail you give me, the better off I'll be when 
> I attempt to reproduce this here.
>
> My guess is you've tickled a bug in GDB's varobj system. But it could be 
> an unknown bug with insight (like not erasing varobjs when needed).
>
> Keith

Ok, here's the procedure.

1. Start insight from kde Konsole:
$ arm-rtems4.8-insight -x ./gdbinit &

2. Click inside insight source window and hit C

3. Program runs "hello world" program and prints the usual to gtkterm 
console (via target serial port) ending with message "hit Any key to 
reboot".

4. I hit a key in gtkterm console window.

5. Program prints a "data abort" message in the gtkterm console. (This 
is expected.)

6. Looking back at the insight source window, the STOP button is RED so 
I press it.

7. Message pops up about SIGTRAP, I hit OK.

8. File abort.c appears in the source window with green bar pointing at 
 while(1) { continue;} construct (infinite loop). This is expected.

9. With mouse I examine some local and global variables. I don't think 
it matters which ones. They pop up in the balloons as expected. Crash 
does *not* occur here while looking a vars with mouse!

10. I go to the insight console window (not gtkterm's) and type gdb cmd
source gdbinit
to redownload the program to the target ram. It seems to reload the 
sections just like at startup (step 1).

11. I click in the insight source window. It is still displaying the 
abort.c code. Probably OK.

12. I hit s (or c) in the source window and insight vanishes. "[1] 
Segmentation fault" prints in kde Konsole.

Note: If I omit step 9, there is no crash in step 12. Also, if I set a 
breakpoint anywhere in the application and examine a variable with the 
mouse, insight crashes after the next "so gdbinit" is loaded. I don't 
actually have to let the program run to completion.