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 jon.tur...@dronecode.org.uk
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 jon.tur...@dronecode.org.uk
* archive_tar_file.cc (read, peek): Return 0 on an error,
not EIO.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
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
