[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] Running 'gtar' compiled on Solaris 9 on Solaris 10 dumps c
From: |
Paul Eggert |
Subject: |
Re: [Bug-tar] Running 'gtar' compiled on Solaris 9 on Solaris 10 dumps core |
Date: |
Sat, 22 Jan 2011 16:26:55 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 |
On 01/21/2011 06:42 AM, Dagobert Michelsen wrote:
> it is expected that a binary compiled on Solaris 9 using standard
> interfaces should run on later versions
Yes, quite true, but there are also bugs in that area, and perhaps
tar is running afoul of them.
It's not clear from the pstack output what the exact sequence of
events is, but if I'm decoding it correctly it sounds like it's
something like this:
gnulib fdutimensat (5, AT_FDCWD, file, ts, AT_SYMLINK_NOFOLLOW)
gnulib utimensat (AT_FDCWD, file, ts, AT_SYMLINK_NOFOLLOW)
gnulib lutimens (file, ts)
gnulib fdutimens (-1, file, ts)
libc futimesat (AT_FDCWD, file, tv)
where file is "hello-0.1.0/hello.texinfo", ts is the desired timespec,
and tv is ts converted to a timeval approximation. At this point
things get pretty weird, because libc futimesat turns around and
calls gnulib with a new struct timespec:
gnulib utimens (file, ts1)
gnulib fdutimens (-1, file, ts1)
and now we're looping around in infinite recursion, each level with
a new timespec (presumably with contents equal to the old).
Could you please run the offending instances of 'tar' under a debugger,
and see whether that's what is happening? Could you also see whether
Solaris 9's library has a (presumably undocumented) utimens interface?
It may help to compile 'tar' without using optimization, in case
cc is doing some tail recursion optimization that messes up the
debugging info.