Re: Need help with gzip trouble on alternate architectures

[Orion Poplawski]

On 12/08/2016 11:39 AM, Orion Poplawski wrote:
> I've updated the octave Fedora package to 4.2.0 in Rawhide, but now I'm having
> trouble building octave packages with it on non-x86 architectures.  In
> desperation I ran the pkg build process under strace and found the following:
>
> 12859 write(4,
> "{&C\354\202\323E\366\0043l(\r\342!\216H\224\302W\201&\265-\272\300\226\235g\227h\26\372A`3\357G\35\314\344\247\371\261Q\t\2138t\7f\230\251\225\346\340F=\204\7\3153C\306;\353\350-\371\255\276\230oe\267w\6\337:\343J\374\362\213,p$u\317\30K\v7\35/\266\357\324
> \335\377", 101) = 101
> 12859 close(4)                          = 0
> 12859 close(3)                          = 0
> 12859 unlinkat(AT_FDCWD,
> "/builddir/build/BUILD/octave-io-2.4.5/build/io-2.4.5-aarch64-redhat-linux-gnu-api-v51.tar.gz",
> 0) = 0
>
> this is it finishing writing the compressed tar file, and then promptly
> deleting it.
>
> Looking at the gzip code, I see:
>
>           try
>             {
>               X::zip (path, dest_path);
>             }
>           catch (...)
>             {
>               // Error "handling" is not including filename on the output list.
>               // Also remove created file which maybe was not even created
>               // in the first place.  Note that it is possible for the file
>               // to exist in the first place and for X::zip to not have
>               // clobber it yet but we remove it anyway by design.
>               octave::sys::unlink (dest_path);
>               return;
>             }
>
> So my guess it that the zip() call threw some kind of exception, although I
> have now idea what.  Although since it got to closing the destination file,
> I'm not sure if that is where the error would have occurred.
>
> Unfortunately I have been unable to duplicate this outside of the Fedora
> builders, so I can't really run it under gdb.
>
> Is there some way that I can get the above code to output the text of the
> exception if there is one?
>
> Any other way to trace the execution of the pkg commands?  Although build does:
>
>     gzip (tar_path, builddir);
>     rmdir (build_root, "s");
>
> although I think I see the rmdir process following the unlink above:
>
> 12859 unlinkat(AT_FDCWD,
> "/builddir/build/BUILD/octave-io-2.4.5/build/io-2.4.5-aarch64-redhat-linux-gnu-api-v51.tar.gz",
> 0) = 0
> 12859 openat(AT_FDCWD, "/builddir/build/BUILD/octave-io-2.4.5/build/io",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> 12859 fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> 12859 getdents64(3, /* 9 entries */, 32768) = 240
> 12859 getdents64(3, /* 0 entries */, 32768) = 0
> 12859 newfstatat(AT_FDCWD,
> "/builddir/build/BUILD/octave-io-2.4.5/build/io/DESCRIPTION",
> {st_mode=S_IFREG|0644, st_size=494, ...}, AT_SYMLINK_NOFOLLOW) = 0
> 12859 unlinkat(AT_FDCWD,
> "/builddir/build/BUILD/octave-io-2.4.5/build/io/DESCRIPTION", 0) = 0
> ....
>
> So I do think it is gzip that is deleting the gzipped tar file.
>
> TIA,
>
>   Orion

Okay, I built with this patch:

diff -up octave-4.2.0/libinterp/dldfcn/gzip.cc.gzip 
octave-4.2.0/libinterp/dldfcn/gzip.cc
--- octave-4.2.0/libinterp/dldfcn/gzip.cc.gzip  2016-11-13 
08:16:10.000000000 -0700
+++ octave-4.2.0/libinterp/dldfcn/gzip.cc       2016-12-08 
13:23:56.325297196 -0700
@@ -449,14 +449,15 @@ namespace octave
             {
               X::zip (path, dest_path);
             }
-          catch (...)
+          catch ( const std::exception & ex )
             {
+              warning ("gzip: zip threw exception %s", ex.what());
               // Error "handling" is not including filename on the 
output list.
               // Also remove created file which maybe was not even created
               // in the first place.  Note that it is possible for the 
file
               // to exist in the first place and for X::zip to not have
               // clobber it yet but we remove it anyway by design.
-              octave::sys::unlink (dest_path);
+              //octave::sys::unlink (dest_path);
               return;
             }
           dest_paths.push_front (dest_path);

this resulted in:

warning: gzip: zip threw exception failed to close zlib stream
warning: called from
    build at line 86 column 5
    pkg at line 515 column 7

and indeed the compressed file seems to be bad:

untar 
(/builddir/build/BUILD/octave-control-3.0.0/build/control-3.0.0-powerpc64-redhat-linux-gnu-api-v51.tar.gz, 
/tmp/oct-yGKWud)
gzip: 
/builddir/build/BUILD/octave-control-3.0.0/build/control-3.0.0-powerpc64-redhat-linux-gnu-api-v51.tar.gz: 
unexpected end of file
unpack: unarchiving program exited with status: 2
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
error: unhandled execution exception -- eval failed

so the exception is coming from:

      close (void)
      {
        if (deflateEnd (strm) != Z_OK)
          throw std::runtime_error ("failed to close zlib stream");

now to figure out why deflatedEnd isn't working.  Ideas anyone?


--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  address@hidden
Boulder, CO 80301              http://www.cora.nwra.com