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
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

- Raw text -