Re: segmentation fault on exit in Insight 5.0

[Chris Faylor <cgf at cygnus dot com>]

On Wed, Jun 28, 2000 at 02:27:40PM -0700, Jim Ingham wrote:
>Also sprach Chris Faylor:
>
>> On Tue, Jun 27, 2000 at 10:21:36AM -0700, Nicholas_Karagas@cirilium.com wrote:
>>> Hello again,
>>> 
>>> I tried downloading the gdb/Insight 5.0 release, and still have the same
>>> problem (SIGSEGV when exiting).  Here's the complete backtrace (actually,
>>> all output) from debugging the Insight session.  All I did was start
>>> Insight with my .gdbinit file and immediately exit.  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.  I am connecting to a remote
>>> m68k via Remote/Serial at 38400 baud.  I am running Cygwin 1.1.0(0.18/3/2)
>>> (from uname -r) on WINNT 4.0 (Build 1381: Service Pack 6).  Any help on
>>> this would be greatly appreciated.  Thanks.
>>> 
>>> GNU gdb 4.17.1
>> ^^^^^^
>> This is not gdb 5.0.
>
>Chris,
>
>I think he is using a 4.17.1 version of gdb to debug the gdb crash.  That is
>not the version of Insight that he is trying to run...

Yeah, he sent me private email apprising me of this situation.

I was lulled into a false sense of superiority because we recently
had exactly this problem on the cygwin mailing list.  Somebody was
complaining about running the "new" version of gdb and their version
string showed "4.17-GNATS" or something like that.

On rereading, I share your concerns about running a tarnished version
of remote.c

cgf

>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