delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |