This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin Setup: Fatal Error: Uncaught Exception


On Tue, 24 Jan 2006, Yitzchak Scott-Thoennes wrote:

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

What Brian said.  I've since managed to reproduce the problem with a
zero-sized tarball (but you're right, anything with a mismatched size or
md5 hash would have worked -- or, rather, not worked) and posted a patch.
I would appreciate some comments on the discussion we had with Brian (on
cygwin-apps).
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]