1.5.1: lseek64 woes (was Re: 1.5.1: unzip problems with binary files in archive)

[David Rothenberger]

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/