From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16864 invoked by alias); 7 Jun 2002 14:14:26 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 16857 invoked from network); 7 Jun 2002 14:14:25 -0000 Received: from unknown (HELO smtp.idealapps.com) (216.217.129.55) by sources.redhat.com with SMTP; 7 Jun 2002 14:14:25 -0000 Received: from ddcmail.detroitdiesel.com (ddcmail.detroitdiesel.com [12.47.84.11]) by smtp.idealapps.com (8.11.4/8.11.4) with SMTP id g57EEsg12982 for ; Fri, 7 Jun 2002 10:14:54 -0400 (EDT) Received: from 148.99.32.99 by ddcmail.detroitdiesel.com with ESMTP ( Detroit Diesel Mail Relay (MMS v4.7)); Fri, 07 Jun 2002 10:10:07 -0400 X-Server-Uuid: 28431ec2-fd89-11d2-a089-00a0c9f498e6 Received: by ddcexch.ddcnet.detroitdiesel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 10:14:23 -0400 Message-ID: <0DB4E7930F5CD411AC93009027EE744C0DE7659F@ddcexch.ddcnet.detroitdiesel.com> From: "Kilroy, David" To: "'cygwin@cygwin.com'" Subject: RE: Re[3]: cygwin download incomplete - try again - loop? Date: Fri, 07 Jun 2002 08:04:00 -0000 MIME-Version: 1.0 X-WSS-ID: 111E613519408-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00398.txt.bz2 > 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/