Re: segmentation fault on exit in Insight 5.0

[Nicholas_Karagas@cirilium.com]

>OTOH, I am made nervous by the statement "Note that the line numbers for
>remote.c may not match yours exactly, as I have some stuff specific to our
>particular setup in there."  Given that the crash is down below
remote_kill,
>Nicholas really needs to try this with the vanilla version of Insight if
he
>can, and see if he gets the crash there.  I haven't heard any reports of
>Insight crashing like this on some other systems, so with no disrespect to
>Nicholas, we really need to remove his code from the loop first, before we
>can help with the problem further...
>
>Jim

The remote.c stuff is just sending a couple of extra characters to the
target, no big deal.  I've actually tracked down and solved the problem,
though.  What I don't really understand is why am I the only one seeing
this?  Does everyone else just use the close box :)  The problem is this:
When you select 'Exit' from the file menu, it runs (after some other stuff)
gdb_force_quit, which runs quit_force from top.c.  One of the last things
that quit_force does, through some function or other, is to delete all of
the remaining windows.  Now, there is some code in managedwin.ith that
says, 'when you delete the last window, call gdb_force_quit'.  Oops!  I
don't know if this little bit of recursion is intentional, but it causes a
SIGSEGV because it causes gdb to try to close the remote target again,
after the scb (serial control block?) has already been deallocated by the
previous quit_force.  To solve, I changed the following (sorry, I don't
know how to use CVS so I can't give you the changes in a nicer format):  I
changed quit_if_last in managedwin.ith to return 0 instead of 1, so that it
no longer calls gdb_force_quit whan the last window is deleted.  This
unfortunately breaks closing the program with the close box, so I had to
make the following changes to _exit in srcwin.itb:

body SrcWin::_exit {} {
    debug
    if {[llength [ManagedWin::find SrcWin]] == 1} {
      gdbtk_quit
    } else {
      after idle [delete object $this]
    }
  }

This way, quit_force does not ever have to be called from the destructor of
the last window, which (IMHO) provides more consistant behavior.  Let me
know if you think these are good changes, or if you have a better fix.

Nicholas Karagas
Associate Software Engineer
Cirilium Corporation
Tempe, AZ
(480) 317-1144