1.5.1: lseek64 woes (was Re: 1.5.1: unzip problems with binary files in archive)
David Rothenberger
daveroth@acm.org
Tue Jul 29 10:32:00 GMT 2003
Charles Wilson writes:
> Christopher Faylor wrote:
>
> >>>>I'm getting a strange error from unzip when trying to extract an
> >>>>archive that contains binary files. Everything works fine if the
> >>>>archive contains just text files.
> >>>
> >>>Can't duplicate it. Sorry.
> >>
> I --can-- duplicate it. But I don't know why it happens; I'll have to
> debug it...but not until after I update to 1.5.1. FWIW, zip does use
> fdopen().
I've done some debugging and I have a STC. I have no idea why it
fails, and why Chris doesn't see it, but here's the info.
The STC is composed of the two attached files: works.c and fails.c.
Both files essentially do
int fd = open("works.c", 0);
lseek(fd, 1, 0);
but works.c does this directly in main(), while fails.c does this in
unzip() called from main(). As you can guess, lseek() returns -1 in
fails.c and 1 in works.c.
The strace output is interesting.
$ gcc -o works works.c
$ strace --mask=syscall ./works | grep lseek
[*] 100 47928 [main] works 1536 lseek64: lseek (3, 1, 0)
227 48155 [main] works 1536 lseek64: 1 = lseek (0, 3, 0)
$ gcc -o fails fails.c
$ strace --mask=syscall ./fails | grep lseek
[*] 96 36666 [main] fails 1908 lseek64: lseek (3, 1, 0)
[*] 79 36745 [main] fails 1908 lseek64: dir is invalid (1627411387)
76 36821 [main] fails 1908 lseek64: -1 = lseek (-1, 3, 0)
[*] I added these:
Index: syscalls.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.278
diff -u -p -r1.278 syscalls.cc
--- syscalls.cc 26 Jul 2003 04:53:59 -0000 1.278
+++ syscalls.cc 29 Jul 2003 05:18:01 -0000
@@ -541,8 +541,11 @@ lseek64 (int fd, _off64_t pos, int dir)
_off64_t res;
sigframe thisframe (mainthread);
+ syscall_printf("lseek (%d, %lld, %d)", fd, pos, dir);
+
if (dir != SEEK_SET && dir != SEEK_CUR && dir != SEEK_END)
{
+ syscall_printf("dir is invalid (%d)", dir);
set_errno (EINVAL);
res = -1;
}
The output shows that dir is fine right before the if statement, but
not after.
(The output above was generated using the dll from CVS HEAD compiled
with mknetrel. When compiled with "-g" only, both cases fail,
although the incorrect dir value for the works.c is 2048, much lower
than value for fails.c, which is of the same magnitude as the value
above.)
The tests work as originally described with the official 1.5.1 dll,
although without the added syscall_printf()'s. However, even the
stock strace output is weird. The output is
79 123229 [main] fails 2308 lseek64: -1 = lseek (-1, 3, 0)
but the printf is
syscall_printf ("%d = lseek (%d, %D, %d)", res, fd, pos, dir);
which means
res = -1 (okay)
fd = -1 (should be 3)
pos = 3 (should be 1)
dir = 0 (okay)
At least I think so. I'm not sure what "%D" means....
I've attached another cygcheck output because the original report
was generated from a fresh 1.5.1 installation while this one is CVS
HEAD with all test packages installed.
HTH,
Dave
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: works.c
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030729/9ddc5907/attachment.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fails.c
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030729/9ddc5907/attachment-0001.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygcheck.out
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030729/9ddc5907/attachment.ksh>
-------------- next part --------------
--
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/
More information about the Cygwin
mailing list