Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
On 06/03/2016 02:38 PM, John Paul Adrian Glaubitz wrote: > I will verify the configuration again. Ok, so there was indeed one strange issue which was that /dev/shm in the host system was mounted again when invoking any schroot command, so that after running schroot once, mount on the host system showed three mounts of shm: Before calling schroot: root@landau:~# mount |grep shm tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) After calling schroot -c sid1-sparc64-sbuild in a second terminal: root@landau:~# mount |grep shm tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/schroot/mount/sid1-sparc64-sbuild-134f6ca3-bd12-4b3c-a389-cfacf7bb2c35/dev/shm type tmpfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,relatime) Either way, this has been fixed now. Let's try again :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
Hi! On 06/03/2016 02:26 PM, Aurelien Jarno wrote: > 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. Hmm, that's odd. I have just verified this again: root@landau:~# schroot -c sid1-sparc64-sbuild (sid1-sparc64-sbuild)root@landau:~# mount /dev/vdiskc1 on / type ext4 (rw,relatime,data=ordered) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=66386376k,nr_inodes=8298297,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,relatime) (sid1-sparc64-sbuild)root@landau:~# Additionally, /etc/schroot/buildd/fstab and /etc/schroot/chroot.d/* look fine, so I'm not sure what else is missing. I have seen gcc-5 and gcc-6 sporadically complain about insufficient ptys, too. So there might be something wrong with the fstab configuration. I will verify the configuration again. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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.ced7552753334000p-4 > | should be: -1.12998111847613019742e-01 -0x1.ced71bae52efa000p-4 > | difference: 2.14102343770727898687e-07 0x1.cbc8021dp-23 > | ulp : 15427699770. > | max.ulp : 8. > | > | 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 aurel...@aurel32.net http://www.aurel32.net
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
> > 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? I sent the wcsmbs/test-wcsncmp patch to glibc upstream a couple of days ago. It still needs approval.
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
On 31 May 2016, John Paul Adrian Glaubitz uttered the following: > On 05/31/2016 04:13 PM, Aurelien Jarno wrote: >>> 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. I was only commenting on how to stop the spurious timeouts. TIMEOUTFACTOR won't make bus errors go away. :)
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
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.ced7552753334000p-4 | should be: -1.12998111847613019742e-01 -0x1.ced71bae52efa000p-4 | difference: 2.14102343770727898687e-07 0x1.cbc8021dp-23 | ulp : 15427699770. | max.ulp : 8. | | 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. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
On 05/31/2016 04:26 PM, Nick Alcock wrote: >> Hmm, then I'm a bit out of ideas. The idea came from Nick Alcock, so maybe >> he can comment on this as well. > > I was only commenting on how to stop the spurious timeouts. > TIMEOUTFACTOR won't make bus errors go away. :) Oh, no, I wasn't talking about this bus error but remaining test failures I was seeing after applying Jose's patch. I have made a test build with Jose's patch applied as well as setting TIMEOUTFACTOR to 100, the result can be seen in the log in [1]. Adrian > [1] > https://people.debian.org/~glaubitz/glibc_2.22-9+sparc64_sparc64-20160530-2024.build -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
(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. Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=glibc=sparc64=2.22-7=1462606555 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
On 2016-05-31 00:21, John Paul Adrian Glaubitz wrote: > Source: glibc > Version: 2.22-9 > Severity: normal > Tags: patch > User: debian-sp...@lists.debian.org > Usertags: sparc64 > > Hi! > > glibc currently fails to build from source on sparc64 due at least one test > in the testsuite failing which is due to a bus error (unaligned access): > > -- > 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. > I have notified glibc upstream of these issue - not in a bug report but by > talking to one of the developers and I have now a patch that fixes the > problem [1]. > > This patch applies cleanly to glibc 2.22-9 in Debian unstable when dropping > the Changelog part from the upstream patch, so I'm attaching a patch with > this part removed as a suggestion for what to include in the Debian package. Thanks for submitting the patch upstream. Given the above, I think it is better to wait for an answer from upstream before applying it. > 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. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#825865: glibc: Testsuite failure on sparc64 due to unaligned access in wcsmbs/test-wcsncmp.c
Source: glibc
Version: 2.22-9
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hi!
glibc currently fails to build from source on sparc64 due at least one test
in the testsuite failing which is due to a bus error (unaligned access):
--
XFAIL: wcsmbs/test-wcsncmp
original exit status 1
wcsncmp simple_wcsncmp stupid_wcsncmp
Didn't expect signal from child: got `Bus error'
--
I have notified glibc upstream of these issue - not in a bug report but by
talking to one of the developers and I have now a patch that fixes the
problem [1].
This patch applies cleanly to glibc 2.22-9 in Debian unstable when dropping
the Changelog part from the upstream patch, so I'm attaching a patch with
this part removed as a suggestion for what to include in the Debian package.
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).
Cheers,
Adrian
> [1] https://sourceware.org/ml/libc-alpha/2016-05/msg00710.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Description: Fix string/test-strncmp.c to work with wide chars.
wcsmbs/test-wcsncmp.c (i.e. string/test-strncmp with defined WIDE)
triggers a signal in aligment-strict platforms, like sparc*-*-*.
.
This patch fixes string/test-strncmp.c to work properly when the test is
performed on arrays of wide chars. This includes passing align1 and
align2 to do_test as bytes, and to use more meaningful values for middle
chars and large chars.
.
--- glibc-2.22.orig/string/test-strncmp.c
+++ glibc-2.22/string/test-strncmp.c
@@ -38,6 +38,8 @@
# define CHAR wchar_t
# define UCHAR wchar_t
# define CHARBYTES 4
+# define MIDCHAR 0x7fff
+# define LARGECHAR 0xfffe
# define CHAR__MAX WCHAR_MAX
# define CHAR__MIN WCHAR_MIN
@@ -88,6 +90,8 @@ stupid_wcsncmp (const CHAR *s1, const CH
# define CHAR char
# define UCHAR unsigned char
# define CHARBYTES 1
+# define MIDCHAR 0x7f
+# define LARGECHAR 0xfe
# define CHAR__MAX CHAR_MAX
# define CHAR__MIN CHAR_MIN
@@ -414,56 +418,56 @@ test_main (void)
for (i =0; i < 16; ++i)
{
- do_test (0, 0, 8, i, 127, 0);
- do_test (0, 0, 8, i, 127, -1);
- do_test (0, 0, 8, i, 127, 1);
- do_test (i, i, 8, i, 127, 0);
- do_test (i, i, 8, i, 127, 1);
- do_test (i, i, 8, i, 127, -1);
- do_test (i, 2 * i, 8, i, 127, 0);
- do_test (2 * i, i, 8, i, 127, 1);
- do_test (i, 3 * i, 8, i, 127, -1);
- do_test (0, 0, 8, i, 255, 0);
- do_test (0, 0, 8, i, 255, -1);
- do_test (0, 0, 8, i, 255, 1);
- do_test (i, i, 8, i, 255, 0);
- do_test (i, i, 8, i, 255, 1);
- do_test (i, i, 8, i, 255, -1);
- do_test (i, 2 * i, 8, i, 255, 0);
- do_test (2 * i, i, 8, i, 255, 1);
- do_test (i, 3 * i, 8, i, 255, -1);
+ do_test (0, 0, 8, i, MIDCHAR, 0);
+ do_test (0, 0, 8, i, MIDCHAR, -1);
+ do_test (0, 0, 8, i, MIDCHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 0);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, -1);
+ do_test (CHARBYTES * i, 2 * CHARBYTES * i, 8, i, MIDCHAR, 0);
+ do_test (2 * CHARBYTES * i, CHARBYTES * i, 8, i, MIDCHAR, 1);
+ do_test (CHARBYTES * i, 3 * CHARBYTES * i, 8, i, MIDCHAR, -1);
+ do_test (0, 0, 8, i, LARGECHAR, 0);
+ do_test (0, 0, 8, i, LARGECHAR, -1);
+ do_test (0, 0, 8, i, LARGECHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 0);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 1);
+ do_test (CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, -1);
+ do_test (CHARBYTES * i, 2 * CHARBYTES * i, 8, i, LARGECHAR, 0);
+ do_test (2 * CHARBYTES * i, CHARBYTES * i, 8, i, LARGECHAR, 1);
+ do_test (CHARBYTES * i, 3 * CHARBYTES * i, 8, i, LARGECHAR, -1);
}
for (i = 1; i < 8; ++i)
{
- do_test (0, 0, 8 << i, 16 << i, 127, 0);
- do_test (0, 0, 8 << i, 16 << i, 127, 1);
- do_test (0, 0, 8 << i, 16 << i, 127, -1);
- do_test (0, 0, 8 << i, 16 << i, 255, 0);
- do_test (0, 0, 8 << i, 16 << i, 255, 1);
- do_test (0, 0, 8 << i, 16 << i, 255, -1);
- do_test (8 - i, 2 * i, 8 << i, 16 << i, 127, 0);
- do_test (8 - i, 2 * i, 8 << i, 16 << i, 127, 1);
- do_test (2 * i, i, 8 << i, 16 << i, 255, 0);
- do_test (2 * i, i, 8 << i, 16 << i, 255, 1);
-}
-
- do_test_limit (0, 0, 0, 0, 127, 0);
- do_test_limit (4, 0, 21, 20, 127, 0);
- do_test_limit (0, 4, 21, 20, 127, 0);
- do_test_limit (8, 0, 25, 24, 127, 0);
- do_test_limit (0, 8, 25, 24, 127, 0);
+ do_test (0, 0, 8 << i, 16 << i, MIDCHAR,
