make check failing on times with -m32

[Dmitry V. Levin]

Hi,

On Fri, Jan 15, 2016 at 02:02:56AM +0000, Steve McIntyre wrote:
> On Thu, Jan 14, 2016 at 02:31:01AM +0000, Steve McIntyre wrote:
> >On Thu, Jan 14, 2016 at 05:00:30AM +0300, Dmitry V. Levin wrote:
> >>On Fri, Jan 08, 2016 at 05:33:08PM +0000, Steve McIntyre wrote:
> >>[...]
> >>> Thanks, that seems to work - all the tests pass now.
> >>> 
> >>> 4.11-1 is in Debian incoming right now with this as the only code
> >>> change on top of what was released in 4.11.
> >>
> >>According to https://buildd.debian.org/status/package.php?p=strace
> >>it failed several tests on some architectures.
> >>
> >>I'm not surprised by mips test failures since mips had relatively poor
> >>prerelease testing, but arm and alpha were expected to pass their tests.
> >>
> >>Unfortunately, "make check" was made without VERBOSE=1 specified,
> >>so there are no details why those tests failed.
> >>
> >>Steve, could you re-run "make check" with VERBOSE=1
> >>on failed architectures to get some details?
> >
> >Coincidentally, I've just been doing exactly that already this
> >evening. I'm in the middle of hacking on a script to run tests
> >periodically on the various Debian porter boxes, so should be able to
> >give you some better and more timely results in future too.
> >
> >Results from VERBOSE=1 shortly.
> 
> Here's the failing snippet from an armhf machine:
> 
> FAIL: lseek
> ===========
> 
> + ../strace -V
> + TIMEOUT=timeout -s 9 60
> + timeout -s 9 60 true
> + exec timeout -s 9 60 ./lseek.test
> + run_prog
> + [ 0 -eq 0 ]
> + set -- ./lseek
> + args=./lseek
> + ./lseek
> + OUT=lseek.test.tmp.out
> + run_strace -a30 -elseek ./lseek
> + 
> + args=-a30 -elseek ./lseek
> + ../strace -o lseek.test.tmp -a30 -elseek ./lseek
> + match_diff lseek.test.tmp lseek.test.tmp.out
> + local output expected error
> + [ 2 -eq 0 ]
> + output=lseek.test.tmp
> + shift
> + [ 1 -eq 0 ]
> + expected=lseek.test.tmp.out
> + shift
> + [ 0 -eq 0 ]
> + error=../strace -a30 -elseek ./lseek output mismatch
> + check_prog diff
> + type diff
> + diff -- lseek.test.tmp.out lseek.test.tmp
> 0a1,2
> > lseek(3, 1268600, SEEK_SET)   = 1268600
> > lseek(3, 1265140, SEEK_SET)   = 1265140
> + fail_ ../strace -a30 -elseek ./lseek output mismatch

So my wild guess (commit v4.11-162-g8e37cff) was correct,
it must be libc or dynamic linker doing these extra lseek calls,
probably Debian specific, otherwise I'd spotted it myself.

If you are curious enough, try "strace -y -elseek ./lseek"
to reveal the secret.

> + warn_ lseek.test: failed test: ../strace -a30 -elseek ./lseek output
> mismatch
> + printf %s\n lseek.test: failed test: ../strace -a30 -elseek ./lseek
> output mismatch
> lseek.test: failed test: ../strace -a30 -elseek ./lseek output
> mismatch
> + exit 1
> FAIL lseek.test (exit status: 1)
> 
> Discussing this with Dimitri (in CC) on irc, he thinks it's a libc
> issue maybe:
> 
> 2016-01-13 14:39 GMT < xnox> Sledge, i'm poking strace on arm* on a
>      porter box, it looks like there is now exta lseek syscalls done
>      by libc itself, prior to executing anything. and they show up in
>      the strace output... and thus failing strace lseek test-suite, as
>      it's not expecting to see the two lseek calls from libc.

I agree with this analysis.

> 2016-01-13 14:39 GMT < xnox> so i believe strace is working
>      correctly. Is there a place in a test-suite to filterout bogus
>      things that are coming from libc?
> 2016-01-13 14:39 GMT < xnox> or should libc not do lseek calls?

If something is doing a lseek system call on a 32-bit system,
it has to be fixed to call _llseek instead.  But that's another story.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160115/b6d236b1/attachment.bin>