Bug#803927: Please test eglibc 2.11.3-4+deb6u8

[Ben Hutchings]

On Wed, 2015-11-25 at 01:27 +0100, Raphael Hertzog wrote:
> On Tue, 24 Nov 2015, Ben Hutchings wrote:
> > You should copy out the test output file so it's possible to see which
> > step of the mqueue5 test failed.
> > 
> > There are some recent changes to the mqueue implementation in Linux
> > that might possibly have caused this (not because they are known buggy,
> > but they may have user-visible effects).  However it's fairly pointless
> > for me to look any further without that test output.
> 
> In a build in a normal chroot (not a minimal-sbuild one), I only got the 
> failure
> for the amd64-i386 build:
> ┏(squeeze-amd64) x230-buxy:~/deb/lts/pkg/eglibc-2.11.3
> ┗(543)$ cat build-tree/amd64-i386/rt/tst-mqueue5.out 
> SIGRTMIN signal in child did not arrive
> child failed with status 256

The test doesn't fail reliably.  Running tst-mqueue5 program against
the current libc6-686, 7 out of 100 runs failed in this way.  Running
it against the new libc6, 8 out of 100 failed.  (Both in a squeeze:i386
chroot with a 4.2 amd64 kernel.)

Whatever is going wrong here, I don't think it's a regression.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

signature.asc
Description: This is a digitally signed message part

Bug#803927: Please test eglibc 2.11.3-4+deb6u8

[Raphael Hertzog]

On Tue, 24 Nov 2015, Ben Hutchings wrote:
> You should copy out the test output file so it's possible to see which
> step of the mqueue5 test failed.
> 
> There are some recent changes to the mqueue implementation in Linux
> that might possibly have caused this (not because they are known buggy,
> but they may have user-visible effects).  However it's fairly pointless
> for me to look any further without that test output.

In a build in a normal chroot (not a minimal-sbuild one), I only got the failure
for the amd64-i386 build:
┏(squeeze-amd64) x230-buxy:~/deb/lts/pkg/eglibc-2.11.3
┗(543)$ cat build-tree/amd64-i386/rt/tst-mqueue5.out 
SIGRTMIN signal in child did not arrive
child failed with status 256

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#803927: Please test eglibc 2.11.3-4+deb6u8

[Ben Hutchings]

On Tue, 2015-11-24 at 17:23 +0100, Raphael Hertzog wrote:
> Hello,
> 
> I have backported the upstream patch for squeeze and it results in the
> attached patch. It does compile and I have not identified any regression
> but the build log mentions unexpected testsuite failures.
> 
> Comparing with a build of the the previous version, I get only one
> supplementary failure:
> @@ -50775,10 +50775,12 @@
>  bug-regex32.out, Error 1
>  check-localplt.out, Error 1
>  tst-atime.out, Error 1
> +tst-mqueue5.out, Error 1
>  ***
>  Encountered regressions that don't match expected failures:
>  bug-regex32.out, Error 1
>  tst-atime.out, Error 1
> +tst-mqueue5.out, Error 1
>  ***
[...]

You should copy out the test output file so it's possible to see which
step of the mqueue5 test failed.

There are some recent changes to the mqueue implementation in Linux
that might possibly have caused this (not because they are known buggy,
but they may have user-visible effects).  However it's fairly pointless
for me to look any further without that test output.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

signature.asc
Description: This is a digitally signed message part

Bug#803927: Please test eglibc 2.11.3-4+deb6u8

[Raphael Hertzog]

Hello,

I have backported the upstream patch for squeeze and it results in the
attached patch. It does compile and I have not identified any regression
but the build log mentions unexpected testsuite failures.

Comparing with a build of the the previous version, I get only one
supplementary failure:
@@ -50775,10 +50775,12 @@
 bug-regex32.out, Error 1
 check-localplt.out, Error 1
 tst-atime.out, Error 1
+tst-mqueue5.out, Error 1
 ***
 Encountered regressions that don't match expected failures:
 bug-regex32.out, Error 1
 tst-atime.out, Error 1
+tst-mqueue5.out, Error 1
 ***

Both for the amd64 and the i386 version (when built on a squeeze
chroot in a current sid system).

Do you have any idea what this means?

I looked at the test and I don't see how the changes to strxfrm
can result in a regression in that code.

I have uploaded my package here:
http://people.debian.org/~hertzog/packages/eglibc_2.11.3-4+deb6u8_amd64.changes

Dear LTS users, feel free to test them and to report back any regression.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
>From 0f9e585480edcdf1e30dc3d79e24b84aeee516fa Mon Sep 17 00:00:00 2001
From: Leonhard Holz 
Date: Tue, 13 Jan 2015 11:33:56 +0530
Subject: [PATCH] Fix memory handling in strxfrm_l [BZ #16009]

[Modified from the original email by Siddhesh Poyarekar]

This patch solves bug #16009 by implementing an additional path in
strxfrm that does not depend on caching the weight and rule indices.

In detail the following changed:

* The old main loop was factored out of strxfrm_l into the function
do_xfrm_cached to be able to alternativly use the non-caching version
do_xfrm.

* strxfrm_l allocates a a fixed size array on the stack. If this is not
sufficiant to store the weight and rule indices, the non-caching path is
taken. As the cache size is not dependent on the input there can be no
problems with integer overflows or stack allocations greater than
__MAX_ALLOCA_CUTOFF. Note that malloc-ing is not possible because the
definition of strxfrm does not allow an oom errorhandling.

* The uncached path determines the weight and rule index for every char
and for every pass again.

* Passing all the locale data array by array resulted in very long
parameter lists, so I introduced a structure that holds them.

* Checking for zero src string has been moved a bit upwards, it is
before the locale data initialization now.

* To verify that the non-caching path works correct I added a test run
to localedata/sort-test.sh & localedata/xfrm-test.c where all strings
are patched up with spaces so that they are too large for the caching path.
---
 ChangeLog   |  16 ++
 NEWS|  16 +-
 localedata/sort-test.sh |   7 +
 localedata/xfrm-test.c  |  52 +-
 string/strxfrm_l.c  | 488 ++--
 5 files changed, 471 insertions(+), 108 deletions(-)

--- a/localedata/sort-test.sh
+++ b/localedata/sort-test.sh
@@ -30,11 +30,17 @@ for l in $lang; do
${common_objpfx}localedata/xfrm-test $id < $cns.in \
> ${common_objpfx}localedata/$cns.xout || here=1
   cmp -s $cns.in ${common_objpfx}localedata/$cns.xout || here=1
+  LOCPATH=${common_objpfx}localedata GCONV_PATH=${common_objpfx}/iconvdata \
+   LC_ALL=$l ${run_program_prefix} \
+   ${common_objpfx}localedata/xfrm-test $id -nocache < $cns.in \
+   > ${common_objpfx}localedata/$cns.nocache.xout || here=1
+  cmp -s $cns.in ${common_objpfx}localedata/$cns.nocache.xout || here=1
   if test $here -eq 0; then
 echo "$l xfrm-test OK"
   else
 echo "$l xfrm-test FAIL"
 diff -u $cns.in ${common_objpfx}localedata/$cns.xout | sed 's/^/  /'
+diff -u $cns.in ${common_objpfx}localedata/$cns.nocache.xout | sed 's/^/  /'
 status=1
   fi
 done
--- a/localedata/xfrm-test.c
+++ b/localedata/xfrm-test.c
@@ -24,7 +24,10 @@
 #include 
 #include 
 #include 
+#include 
 
+/* Keep in sync with string/strxfrm_l.c.  */
+#define SMALL_STR_SIZE 4095
 
 struct lines
 {
@@ -38,6 +41,7 @@ int
 main (int argc, char *argv[])
 {
   int result = 0;
+  bool nocache = false;
   size_t nstrings, nstrings_max;
   struct lines *strings;
   char *line = NULL;
@@ -45,7 +49,18 @@ main (int argc, char *argv[])
   size_t n;
 
   if (argc < 2)
-error (1, 0, "usage: %s ", argv[0]);
+error (1, 0, "usage: %s  [-nocache]", argv[0]);
+
+  if (argc == 3)
+{
+  if (strcmp (argv[2], "-nocache") == 0)
+	nocache = true;
+  else
+	{
+	  printf ("Unknown option %s!\n", argv[2]);
+	  exit (1);
+	}
+}
 
   setlocale (LC_ALL, "");
 
@@ -60,9 +75,9 @@ main (int argc, char *argv[])
 
   while (1)
 {
-  char saved, *newp;
-  int needed;
-  int l;
+  char saved, *word, *newp;
+  size_t l, line_len, needed;
+
   if (getline (, , stdin) < 0)
 	break;
 
@@ -84,10 +99,35 @@ main (int argc, char *argv[])