X-Spam-Check-By: sourceware.org
Date: Tue, 24 Jan 2006 18:44:44 -0800
From: Yitzchak Scott-Thoennes <sthoenna AT efn DOT org>
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin Setup: Fatal Error: Uncaught Exception
Message-ID: <20060125024444.GB4272@efn.org>
References: <43D467F0 DOT 4020706 AT tlinx DOT org> <43D46B88 DOT FD612AE AT dessent DOT net> <20060123112502 DOT GB2188 AT efn DOT org> <Pine DOT GSO DOT 4 DOT 63 DOT 0601231023040 DOT 18707 AT access1 DOT cims DOT nyu DOT edu> <43D52923 DOT C90D9967 AT dessent DOT net> <Pine DOT GSO DOT 4 DOT 63 DOT 0601231435340 DOT 27934 AT access1 DOT cims DOT nyu DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.63.0601231435340.27934@access1.cims.nyu.edu>
User-Agent: Mutt/1.4.2.1i
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On Mon, Jan 23, 2006 at 02:56:39PM -0500, Igor Peshansky wrote:
> Moving to cygwin-apps, as this is likely to get technical.
> 
> On Mon, 23 Jan 2006, Brian Dessent wrote:
> 
> > Igor Peshansky wrote:
> >
> > > I've looked at this a bit.  Here's the weird part: the error says
> > > "Uncaught Exception", but all the throws of that exception appear to be
> > > properly wrapped in try/catch blocks.  So a simple "change exception into
> > > an mbox" kind of solution won't work here.  More debugging is needed.
> >
> > The reason for the box is that the md5 checking was changed to run in a
> > different thread than originally designed (now in the main thread
> > instead of the download thread IIRC) and that thread does not have any
> > particular catch handler for that exception, only the TOPLEVEL_CATCH
> > which punts with the generic error.
> 
> Do you mean packagemeta::ScanDownloadedFiles() calling
> packageversion::scan(), which calls check_for_cached()?  Then yes, this
> isn't properly wrapped in a try/catch.  I'd like to verify that this is
> the culprit (when someone sends me the corrupt tarball), but I think I see
> a proper fix for this.  Will submit a patch shortly.

Just to reemphasize, these are *not* corrupt tarballs.  They are
tarballs exactly as downloaded, extracted, and installed.  It's just
that later the versions on the cygwin mirror became different while
keeping the same version/filename.  I verified in a couple of the
cases that the newer version actually had executables rebuilt, with
slightly different file sizes and timestamps.

I don't think I have any of them around any more, but if you were to
pick a current tarball in your local package directory and un-bzip2 it
and re-bzip2 it with a different compression level, you should see
the problem.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/