Re: [Grep-devel] regex and grep severely broken on HP-UX
Hi Paul, > Some HP-UX versions have a broken 'calloc' that could explain the bug. The > broken 'calloc' returns memory that isn't properly zeroed. Can you > investigate > whether zeroing the calloc memory fixes the bug? Perhaps something like the > attached Gnulib patch? This patch does not help: Even with it, test-regex still crashes in the same way: Assertion failed: err == REG_ESPACE, file ../../gllib/regexec.c, line 1077 FAIL test-regex (exit status: 134) But I found GCC binaries that I can use on this machine, and with this GCC, both the test-regex and all 'grep' tests pass! Out of the four hypotheses (a) Unportable #if code that expands to invalid code for HP-UX cc. (b) A HP-UX cc front-end bug. (c) A HP-UX cc optimization bug. (d) A HP-UX cc code generation bug. we can exclude (c) - since I had no optimization options enabled -, and (a) is unlikely as well - since it would likely have affected the compilation on HP-UX ia64 as well. Conclusion: Either (b) or (d). Bruno
Re: [Grep-devel] regex and grep severely broken on HP-UX
Some HP-UX versions have a broken 'calloc' that could explain the bug. The
broken 'calloc' returns memory that isn't properly zeroed. Can you investigate
whether zeroing the calloc memory fixes the bug? Perhaps something like the
attached Gnulib patch? Thanks.
diff --git a/lib/calloc.c b/lib/calloc.c
index f4545c2b2..31e1ef50c 100644
--- a/lib/calloc.c
+++ b/lib/calloc.c
@@ -31,6 +31,7 @@
#include
#include
+#include
/* Call the system's calloc below. */
#undef calloc
@@ -44,6 +45,7 @@ rpl_calloc (size_t n, size_t s)
void *result;
#if NEED_CALLOC_GNU
+ size_t bytes = n * s;
if (n == 0 || s == 0)
{
n = 1;
@@ -53,7 +55,6 @@ rpl_calloc (size_t n, size_t s)
{
/* Defend against buggy calloc implementations that mishandle
size_t overflow. */
- size_t bytes = n * s;
if (bytes / s != n)
{
errno = ENOMEM;
@@ -64,6 +65,14 @@ rpl_calloc (size_t n, size_t s)
result = calloc (n, s);
+#if NEED_CALLOC_GNU && defined __hpux
+ /* Work around HP-UX bug where resulting memory is not cleared. See:
+ https://support.hpe.com/hpsc/doc/public/display?docId=pdb_na-PHCO_38658
+ */
+ if (result)
+memset (result, 0, bytes);
+#endif
+
#if !HAVE_CALLOC_POSIX
if (result == NULL)
errno = ENOMEM;
diff --git a/m4/calloc.m4 b/m4/calloc.m4
index be10e211f..c6c070d0d 100644
--- a/m4/calloc.m4
+++ b/m4/calloc.m4
@@ -1,4 +1,4 @@
-# calloc.m4 serial 18
+# calloc.m4 serial 19
# Copyright (C) 2004-2018 Free Software Foundation, Inc.
# This file is free software; the Free Software Foundation
@@ -20,33 +20,39 @@ AC_DEFUN([_AC_FUNC_CALLOC_IF],
AC_REQUIRE([AC_TYPE_SIZE_T])dnl
AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
AC_CACHE_CHECK([for GNU libc compatible calloc],
-[ac_cv_func_calloc_0_nonnull],
-[AC_RUN_IFELSE(
- [AC_LANG_PROGRAM(
- [AC_INCLUDES_DEFAULT],
- [[int result = 0;
-char *p = calloc (0, 0);
-if (!p)
- result |= 1;
-free (p);
-p = calloc ((size_t) -1 / 8 + 1, 8);
-if (p)
- result |= 2;
-free (p);
-return result;
- ]])],
- [ac_cv_func_calloc_0_nonnull=yes],
- [ac_cv_func_calloc_0_nonnull=no],
- [case "$host_os" in
- # Guess yes on glibc systems.
- *-gnu* | gnu*) ac_cv_func_calloc_0_nonnull="guessing yes" ;;
- # Guess yes on native Windows.
- mingw*)ac_cv_func_calloc_0_nonnull="guessing yes" ;;
- # If we don't know, assume the worst.
- *) ac_cv_func_calloc_0_nonnull="guessing no" ;;
-esac
- ])])
- case "$ac_cv_func_calloc_0_nonnull" in
+[ac_cv_func_gnu_compatible_calloc],
+[case $host_os in
+ hpux*)
+ # Not easy to check for PHCO_38658, so guess no.
+ ac_cv_func_gnu_compatible_calloc="guessing no" ;;
+ *)
+ AC_RUN_IFELSE(
+ [AC_LANG_PROGRAM(
+ [AC_INCLUDES_DEFAULT],
+ [[int result = 0;
+char *p = calloc (0, 0);
+if (!p)
+ result |= 1;
+free (p);
+p = calloc ((size_t) -1 / 8 + 1, 8);
+if (p)
+ result |= 2;
+free (p);
+return result;
+ ]])],
+ [ac_cv_func_gnu_compatible_calloc=yes],
+ [ac_cv_func_gnu_compatible_calloc=no],
+ [case $host_os in
+ # Guess yes on glibc systems.
+ *-gnu* | gnu*) ac_cv_func_gnu_compatible_calloc="guessing yes" ;;
+ # Guess yes on native Windows.
+ mingw*)ac_cv_func_gnu_compatible_calloc="guessing yes" ;;
+ # If we don't know, assume the worst.
+ *) ac_cv_func_gnu_compatible_calloc="guessing no" ;;
+esac
+ ]);;
+ esac])
+ case $ac_cv_func_gnu_compatible_calloc in
*yes)
$1
;;
diff --git a/modules/calloc-gnu b/modules/calloc-gnu
index ffc8b50ef..5cba38ff4 100644
--- a/modules/calloc-gnu
+++ b/modules/calloc-gnu
@@ -21,7 +21,7 @@ Include:
License:
-GPL
+LGPLv2+
Maintainer:
Jim Meyering
diff --git a/modules/regex b/modules/regex
index 278510c4c..ce513cb91 100644
--- a/modules/regex
+++ b/modules/regex
@@ -19,6 +19,7 @@ ssize_t
alloca-opt [test $ac_use_included_regex = yes]
btowc [test $ac_use_included_regex = yes]
builtin-expect [test $ac_use_included_regex = yes]
+calloc-gnu [test $ac_use_included_regex = yes]
intprops[test $ac_use_included_regex = yes]
langinfo[test $ac_use_included_regex = yes]
libc-config [test $ac_use_included_regex = yes]
Re: [Grep-devel] regex and grep severely broken on HP-UX
On Sun, Dec 16, 2018 at 11:34 AM Bruno Haible wrote: > > So grep worked on HP-UX before because it was using the system regex code? > > I don't know. Maybe GNU grep never worked on HP-UX hppa? Or maybe it worked > only when compiled by gcc? Or maybe the machine I have access to has a > particularly buggy cc compiler? Or maybe GNU grep worked as long as gnulib > contained the "old" GNU regex code and stopped working when we pulled in the > new regex from glibc? I don't know. In any case, at least now we know there's an issue. IMHO, this need not hold up the release.
Re: [Grep-devel] regex and grep severely broken on HP-UX
Hi Jim, > So grep worked on HP-UX before because it was using the system regex code? I don't know. Maybe GNU grep never worked on HP-UX hppa? Or maybe it worked only when compiled by gcc? Or maybe the machine I have access to has a particularly buggy cc compiler? Or maybe GNU grep worked as long as gnulib contained the "old" GNU regex code and stopped working when we pulled in the new regex from glibc? I don't know. Bruno
Re: [Grep-devel] regex and grep severely broken on HP-UX
On Sun, Dec 16, 2018 at 9:16 AM Bruno Haible wrote: > > More on this: > > On HP-UX hppa (both 32-bit and 64-bit mode), regex and grep are broken. > > The result in different gnulib versions is the same (HP-UX hppa, 32-bit): > > Version Result > - > 20140101crash in regexec.c, line 1123 > 20150101crash in regexec.c, line 1123 > 20160101crash in regexec.c, line 1123 > 20170101crash in regexec.c, line 1104 > 20180101crash in regexec.c, line 1073 > 20181216crash in regexec.c, line 1077 (even with today's fix by > Assaf+Paul) Wow. So grep worked on HP-UX before because it was using the system regex code?
Re: regex and grep severely broken on HP-UX
More on this: > On HP-UX hppa (both 32-bit and 64-bit mode), regex and grep are broken. The result in different gnulib versions is the same (HP-UX hppa, 32-bit): Version Result - 20140101crash in regexec.c, line 1123 20150101crash in regexec.c, line 1123 20160101crash in regexec.c, line 1123 20170101crash in regexec.c, line 1104 20180101crash in regexec.c, line 1073 20181216crash in regexec.c, line 1077 (even with today's fix by Assaf+Paul) Bruno
Re: regex and grep severely broken on HP-UX
More on this: > On HP-UX 11.31, hppa, in 32-bit mode, with cc, I observe the following > test failures: On HP-UX hppa (both 32-bit and 64-bit mode), regex and grep are broken. On HP-UX ia64 (both 32-bit and 64-bit mode), regex and grep both work fine. Bruno
regex and grep severely broken on HP-UX
On HP-UX 11.31, hppa, in 32-bit mode, with cc, I observe the following test failures: 1) Among the gnulib tests (both from the 'grep' snapshot, as well as from a gnulib testdir): FAIL: test-regex $ ./test-regex Assertion failed: err == REG_ESPACE, file ../../lib/regexec.c, line 1077 ABORT instruction (core dumped) 2) Among the grep tests: $ grep FAIL: tests/test-suite.log # XFAIL: 1 # FAIL: 18 FAIL: backref FAIL: backref-word FAIL: bre FAIL: case-fold-backref FAIL: case-fold-char-range FAIL: empty-line FAIL: ere FAIL: fedora FAIL: foad1 FAIL: inconsistent-range FAIL: match-lines FAIL: null-byte FAIL: posix-bracket FAIL: spencer1 FAIL: spencer1-locale XFAIL: triple-backref FAIL: unibyte-negated-circumflex FAIL: word-multi-file FAIL: write-error-msg Bruno
