Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
On 2016-05-31 17:21, Aurelien Jarno wrote:
> On 2016-05-31 16:23, John Paul Adrian Glaubitz wrote:
> > (Sorry for the confusion, I accidentally used my company email. Please answer to this address).
> >
> > Hi Aurelien!
> >
> > On 05/31/2016 04:13 PM, Aurelien Jarno wrote:
> > >> ----------
> > >> XFAIL: wcsmbs/test-wcsncmp
> > >> original exit status 1
> > >> wcsncmp simple_wcsncmp stupid_wcsncmp
> > >> Didn't expect signal from child: got `Bus error'
> > >> ----------
> > >
> > > While the issue is real, this is not the reason while the package fails
> > > to build from source. The test is marked as XFAIL as shown above.
> >
> > Ok, I see. I thought the problem would still trigger due to the unusual
> > failure.
> >
> > > Thanks for submitting the patch upstream. Given the above, I think it is
> > > better to wait for an answer from upstream before applying it.
> >
> > The test comes from Jose Marchesi who I know is gcc upstream, but I'm
> > not sure about glibc. Jose, could you please comment on this?
> >
> > >> Please note: I was still getting some spurious test failures in rt/tst-mqueue5
> > >> due to timeouts. But those could also be a local issue which needs some further
> > >> investiogation (might be related to TIMEOUTFACTOR in debian/build.mk).
> > >
> > > TIMEOUTFACTOR just increases the timeout, if you don't specify it, the
> > > test will just fail faster.
> >
> > Hmm, then I'm a bit out of ideas. The idea came from Nick Alcock, so maybe
> > he can comment on this as well.
> >
> > What's more strange is that glibc_2.22-7 actually happened to build fine,
> > with the tests enabled [1]. All later builds failed again.
>
> This logs show that a build can be successful with the test-wcsncmp test
> failing (look for "XFAIL: wcsmbs/test-wcsncmp" in the build log).
>
> The other builds fails on andi due to the following issue:
>
> | FAIL: math/test-idouble
> | original exit status 1
> | testing double (inline functions)
> | Failure: Test: Real part of: clog10_upward (-0x9.93d17p-4 + 0x7.c5c8d8p-4 i)
> | Result:
> | is: -1.12998325949956790470e-01 -0x1.ced75527533340000000p-4
> | should be: -1.12998111847613019742e-01 -0x1.ced71bae52efa0000000p-4
> | difference: 2.14102343770727898687e-07 0x1.cbc8021d000000000000p-23
> | ulp : 15427699770.0000
> | max.ulp : 8.0000
> |
> | Test suite completed:
> | 58870 test cases plus 56646 tests for exception flags and
> | 56646 tests for errno executed.
> | 1 errors occurred.
>
> And on u164 due to the rt/tst-mqueue5.
>
> So it just look like rt/tst-mqueue5 is racy and sometimes work. You got
> more chance on the 2.22-7 build.
glibc 2.22-10 has been tried on landau, and the error is different:
FAIL: rt/tst-shm
original exit status 1
It's very likely that /dev/shm (or /run/shm) is not mounted correctly in
the chroot.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: