On 31/03/2011 06:15, Yaakov (Cygwin/X) wrote: > As a potential setup.exe bug, redirecting to cygwin-apps. > > On Thu, 2011-03-31 at 00:54 +0200, Angelo Graziosi wrote: >> It is sometime I have installed a few packages from Cygwinports >> (QT,GCC), but today upgrading (mainly *QT*-4.7.2-1 and *mesa*-7.10.1-2) >> 'setup.exe' seems to hang in extracting /usr/include/GL/glxext.h from >> libGL-devel-7.10.1-2. > > Confirmed. > > (The tarball in question is here:) > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/_DISTRO_/X.Org/mesa/libGL-devel/libGL-devel-7.10.1-2.tar.bz2 > >> Result: my hard drive (C:) is almost full, X does not start any more and >> I can use only Cygwin.bat and mintty. To be short, my Cygwin >> installation is broken :( > > Start by deleting /usr/include/GL/glxext.h, that will free up your hard > drive. Then re-run setup, choosing to KEEP libGL-devel instead of > upgrading. > > Now, as for the cause, the only thing I can think of is that I just > started using pbzip2 for compression in cygport[1]. The bz2's are > supposed to be fully compatible, and neither Cygwin nor MinGW bzip2 have > any problems with the tarball in question. > > So my wild guess is that setup uses libbz2 in a way which is > incompatible with pbzip2-compressed tarballs, as unlikely as it seems. > > Can any setup.exe authors shed any light on this?
I do actually want to install that package, so I took a brief look at this: The first problem is that .bz2 file and the decompressor don't like each other. The decompressor reports the stream has ended partway through decompressing glxext.h. It's very mysterious that it should fail but bunzip2 has no problems with the same file. The second problem is a setup bug: If we get an unexpected short read from the archive stream decompressor, we'll sit in an infinite loop writing garbage to the output file 5 bytes at a time. A patch is attached which fixes that, but since these errors are unreported (see comment in io_stream::copy), we just stop expanding the archive, leaving an incomplete glxext.h
From 3ca6eaca538d496867ac4e5e9faf2cf51162ad2f Mon Sep 17 00:00:00 2001 From: Jon TURNEY <[email protected]> Date: Thu, 31 Mar 2011 14:45:47 +0100 Subject: [PATCH] Don't hang if something goes wrong reading from a tar archive Returning EIO (a small positive integer) as the result of archive_tar_file::read() on an error isn't a good idea, it's indistinguishable from successfully reading a small number of bytes. This causes io_stream::copy() to spin forever if it's reading from an archive stream which terminates unexpectedly early, which can happen on an decompression error. So, return 0 instead 2011-03-31 Jon TURNEY <[email protected]> * archive_tar_file.cc (read, peek): Return 0 on an error, not EIO. Signed-off-by: Jon TURNEY <[email protected]> --- archive_tar_file.cc | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/archive_tar_file.cc b/archive_tar_file.cc index 29a2df7..ed6e515 100644 --- a/archive_tar_file.cc +++ b/archive_tar_file.cc @@ -65,7 +65,7 @@ ssize_t archive_tar_file::read (void *buffer, size_t len) /* unexpected EOF or read error in the tar parent stream */ /* the user can query the parent for the error */ state.lasterr = EIO; - return EIO; + return 0; } } return 0; @@ -96,7 +96,7 @@ ssize_t archive_tar_file::peek (void *buffer, size_t len) /* unexpected EOF or read error in the tar parent stream */ /* the user can query the parent for the error */ state.lasterr = EIO; - return EIO; + return 0; } } return 0; -- 1.7.4
