Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Server-Uuid:	28431ec2-fd89-11d2-a089-00a0c9f498e6
Message-ID:	<0DB4E7930F5CD411AC93009027EE744C0DE7659F@ddcexch.ddcnet.detroitdiesel.com>
From:	"Kilroy, David" <david DOT kilroy AT detroitdiesel DOT com>
To:	"'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject:	RE: Re[3]: cygwin download incomplete - try again - loop?
Date:	Fri, 7 Jun 2002 10:14:22 -0400
MIME-Version:	1.0
X-WSS-ID:	111E613519408-01-01

> Its easy to kludge round this, but it strikes me that the 
> problem would be
> better solved by finding out why a null pointer is being 
> passed in the first
> place. Maybe this weekend :-).

I found this lot out a while ago, but thought a fix had been identified by
Pavel/Max and applied in 2.249.xxx. You guys seemed perfectly on track to
identifying the bug in

http://www.cygwin.com/ml/cygwin/2002-05/msg01527.html

So here goes.

What I found is as follows (setup 2.218... files named, in sq bracket are
the files the code was relocated to in 2.249...)

The null pointer is there because the find routines return the path to
setup.ini relative to your local package directory. This is typically

 [rfc1738 encoded ftp site name]/setup.ini

but for the setup.ini in your local package directory, this is

 setup.ini

In ini.c [IniParseFindVisitor.c], you strip /setup.ini from the end of the
path, and pass the remaining string to rfc1738 to decode the ftp location.
You then store the return string as your mirror site.

In the case of the Local Package directory (and 2.218...), you pass null to
the rfc 1738 routines, and they crash.

I haven't checked lately, but I think in 2.249 you may pass "" to rfc1738 to
avoid crashing - however if you do this, a crash occurs later in install.cc
when you ask rfc1738 to encode an empty string (the mirror site you stored
in ini.cc). I'm not sure, but if you pass "setup.ini" to rfc1738  in ini.cc
[IniParseFindVisitor.cc] the correct behaviour occurs. (I chose to pass
"setup.ini" because this is what the pre md5 checksum setup.exe did).

In my opinion, the rfc1738 code should be fixed so it doesn't choke on null
or empty strings (which I think is reasonable), and then you don't need
special code to identify your local cache.

If I am correct, then ralfs crash [in 2.249.xx] occurs after he has selected
everything, and the install is about to take place.

Hope that helps.


Dave.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -