[Bug-tar] Core dumps in tar-1.26 on Solaris SPARC

[Nelson H. F. Beebe]

We found recently that a build of tar-1.26 on Solaris SPARC on our
main fileserver passed all of its tests and was installed, only to
discover later that clients could not run it; instead, they reported
this error:

        fatal: libc.so.1: version `SUNW_1.22.6' not found

For Oracle licensing reasons, the server runs a slightly newer kernel
than our Solaris SPARC clients.

Similar problems recently with rsync led to trying a build with "-z
noversion" added to LDFLAGS, an action that produced a working rsync
on both server and clients.

The next experiment was to build tar-1.26 on a client system with the
"-z noversion" option, test it with "make check", then propagate the
build tree to the server, and reinstall.  That too fails, but this
time with an apparent infinite loop leading to a segment violation:

        % dbx tar
        (dbx) run xfz anyfile.tar.gz
        process id 3533)
        Reading libc_psr.so.1
        signal SEGV (no mapping at the fault address) in validate_timespec at 
line 89 in file "utimens.c"
        (dbx) where
        =>[1] validate_timespec(timespec = 0xff400104), line 89 in "utimens.c"
          ---- 1 following frame from gwindows -- possible stack overflow
          [2] fdutimens(fd = 5, file = (nil), timespec = 0xff4001e0), line 180 
in "utimens.c"
          [3] futimens(fd = 5, times = 0xff4001e0), at 0x803c4
          [4] futimesat(0x5, 0x0, 0xf07820, 0x4da4abc6, 0x0, 0x0), at 0xff136308
          [5] fdutimens(fd = 5, file = (nil), timespec = 0xff4003f8), line 341 
in "utimens.c"
          [6] futimens(fd = 5, times = 0xff4003f8), at 0x803c4
          [7] futimesat(0x5, 0x0, 0xf07820, 0x4da4abc6, 0x0, 0x0), at 0xff136308
          [8] fdutimens(fd = 5, file = (nil), timespec = 0xff400610), line 341 
in "utimens.c"
          [9] futimens(fd = 5, times = 0xff400610), at 0x803c4
          [10] futimesat(0x5, 0x0, 0xf07820, 0x4da4abc6, 0x0, 0x0), at 
0xff136308
          [11] fdutimens(fd = 5, file = (nil), timespec = 0xff400828), line 341 
in "utimens.c"
          [12] futimens(fd = 5, times = 0xff400828), at 0x803c4
          [13] futimesat(0x5, 0x0, 0xf07820, 0x4da4abc6, 0x0, 0x0), at 
0xff136308
          [14] fdutimens(fd = 5, file = (nil), timespec = 0xff400a40), line 341 
in "utimens.c"
        ...
          [98] fdutimens(fd = 5, file = (nil), timespec = 0xff4044e0), line 341 
in "utimens.c"
          [99] futimens(fd = 5, times = 0xff4044e0), at 0x803c4
          [100] futimesat(0x5, 0x0, 0xf07820, 0x4da4abc6, 0x0, 0x0), at 
0xff136308

For the time being, we have reverted to the last working tar, 1.22, on
our SPARC Solaris systems.

Has anyone else seen this behavior, and if so, is there a simple fix?

The traceback shows that one function is ultimately calling itself,
and seems to come from tar sources in the file tar-1.26/gnu/utimens.c.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: address@hidden  -
- 155 S 1400 E RM 233                       address@hidden  address@hidden -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------