Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <00c301c17ad6$5561d730$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>,
   <cygwin-apps AT sources DOT redhat DOT com>
References: <NCBBIHCHBLCMLBLOBONKCELBCHAA DOT g DOT r DOT vansickle AT worldnet DOT att DOT net>
Subject: Re: prev/curr/test behaviour
Date: Sun, 2 Dec 2001 13:09:10 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 02 Dec 2001 02:10:30.0018 (UTC) FILETIME=[840DEE20:01C17AD6]

----- Original Message -----
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>


> > Hmm, strange.
> >
> > Is that consistent regardless of the souce type -
> > local/installfromnet/download only?
>
> The SIGSEVs are, but where they come from varies:
>
> install from net and download only:
> choose.cc line 541: "if (!pkg->Categories.number ())"
>
> pkg == 0x330009 as I look at it right now, seems "un-pointerlike", but
obviously
> not NULL.  Looking at in the local variable window shows a lot of
0x00's, name
> and installed_from prts == 0x00, and... gdbtk just crashed so I can't
tell you
> more ;-).

Ah, this is what I was cursing about before. I think I'll be warming up
my gdb debugging skills shortly, if I can't figure out what I'm doing
that is killing gdb/gcc. (It may be cruddy c++ output?).

> local:
> gdb locks up in the same manner it did with the endless loop you fixed
before.
> I don't know if that's what it is or not, but that's what it behaves
like.  If
> not running under gdb, it'll GPF.

It's not that. I'm tracking this down (sortof) at the moment.

Rob