Re: [PATCH] testsuite for poll(2)
Le lundi 15 septembre 2008 à 21:21 +0200, Paolo Bonzini a écrit : The poll-tests module that is now available in the GnuLib repository currently fail on OpenBSD: Unconnected socket test... failed (huh, connect succeeded?) Connected sockets test... failed (huh, connect succeeded?) Uhm, this means O_NONBLOCK sockets do not work there? To me, this rather look like a bug in connect_to_socket(), which assume that connecting a non blocking socket should never succeed on first try. Where does this assumption come from? failed (expecting POLLHUP after shutdown) General socket test with fork... failed (expecting POLLHUP after shutdown) This is the same failure more or less. Pipe test... passed At least. :-) Is there something like strace? Can you run it? Unfortunately, I have no direct access to the OpenBSD machine: it's a contributor build bot that compile and launch available code and unit-tests, then report us the results. -- Yoann Vandoorselaere | Responsable RD / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com
Re: [PATCH] testsuite for poll(2)
Yoann Vandoorselaere wrote:
Le lundi 15 septembre 2008 à 21:21 +0200, Paolo Bonzini a écrit :
The poll-tests module that is now available in the GnuLib repository
currently fail on OpenBSD:
Unconnected socket test... failed (huh, connect succeeded?)
Connected sockets test... failed (huh, connect succeeded?)
Uhm, this means O_NONBLOCK sockets do not work there?
To me, this rather look like a bug in connect_to_socket(), which assume
that connecting a non blocking socket should never succeed on first try.
Where does this assumption come from?
From the fact that the socket is listening, but not accepting yet. I
added the check mostly to see how Winsock behaved, but yes, it can be
relaxed for OpenBSD. I pushed the following patch:
diff --git a/tests/test-poll.c b/tests/test-poll.c
index e8beb55..b65b7b3 100644
--- a/tests/test-poll.c
+++ b/tests/test-poll.c
@@ -139,16 +139,12 @@ connect_to_socket (int blocking)
#endif
}
- if (connect (s, (struct sockaddr *) ia, sizeof (ia)) 0)
+ if (connect (s, (struct sockaddr *) ia, sizeof (ia)) 0
+ (blocking || errno != EINPROGRESS))
{
- if (errno != EINPROGRESS)
- {
- perror (connect);
- exit (77);
- }
+ perror (connect);
+ exit (77);
}
- else if (!blocking)
-failed (huh, connect succeeded?);
return s;
}
I suppose you don't have similar build bots for Windows, do you?
Paolo
Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)
Jim Meyering [EMAIL PROTECTED] wrote: I discovered that Solaris 11's /bin/sh exhibits the following surprising behavior: $ /bin/sh -c 'umask 22; (umask 0); umask' That would cause test failures in coreutils, because gl_POSIX_SHELL accepted /bin/sh. The following change is enough to make gl_POSIX_SHELL reject that shell and instead use /bin/bash, which is also provided: posix-shell.m4: reject Solaris 11's /bin/sh (due to umask) * m4/posix-shell.m4 (gl_POSIX_SHELL): Reject a shell that lets a umask modification leak out of a subshell. Otherwise, Solaris 11's /bin/sh would be accepted and thus cause unwarranted failures in coreutils test suite. I've pushed that change.
Re: [PATCH] testsuite for poll(2)
This solved the 'unconnected socket test': Unconnected socket test... passed Connected sockets test... failed (expecting POLLHUP after shutdown) General socket test with fork... failed (expecting POLLHUP after shutdown) Yes, it was not meant to fix the others. Paolo
Re: please add scandir, alphasort, versionsort
Michael Haubenwallner wrote: Can I help somehow? Eric is right: First, you need to submit a copyright assignment for your gnulib contributions to the FSF. Then, since these functions are pretty OS independent, you could take their glibc implementation, add a module description, an autoconf macro, and a basic unit test, and contribute that to gnulib. On Solaris for example, they are available starting with Solaris 10, but I have the need to port some package to Solaris 8 and 9. Right, this finding matches what my database of availability of functions on various systems [1] tells. I'm updating the gnulib doc. Bruno [1] http://www.haible.de/bruno/various-symlists.tar.gz 2008-09-16 Bruno Haible [EMAIL PROTECTED] * doc/glibc-functions/scandir.texi: Mention the function is missing on Solaris 9. * doc/glibc-functions/alphasort.texi: Likewise. Reported by Michael Haubenwallner [EMAIL PROTECTED]. --- doc/glibc-functions/alphasort.texi.orig 2008-09-16 13:03:47.0 +0200 +++ doc/glibc-functions/alphasort.texi 2008-09-16 13:02:25.0 +0200 @@ -12,5 +12,5 @@ @itemize @item This function is missing on some platforms: -mingw, BeOS. +Solaris 9, mingw, BeOS. @end itemize --- doc/glibc-functions/scandir.texi.orig 2008-09-16 13:03:47.0 +0200 +++ doc/glibc-functions/scandir.texi2008-09-16 13:02:24.0 +0200 @@ -12,5 +12,5 @@ @itemize @item This function is missing on some platforms: -mingw, BeOS. +Solaris 9, mingw, BeOS. @end itemize
Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/16/2008 3:58 AM: Jim Meyering [EMAIL PROTECTED] wrote: I discovered that Solaris 11's /bin/sh exhibits the following surprising behavior: $ /bin/sh -c 'umask 22; (umask 0); umask' We should also document this in the autoconf manual. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjPqjIACgkQ84KuGfSFAYAaQgCePsvgEpaBmjj8yzWy12pTG8vo wQYAoKqLVm7+8CpKVoTX9/5CiwBlh4a1 =4APv -END PGP SIGNATURE-
Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)
Eric Blake wrote: According to Jim Meyering on 9/16/2008 3:58 AM: Jim Meyering [EMAIL PROTECTED] wrote: I discovered that Solaris 11's /bin/sh exhibits the following surprising behavior: $ /bin/sh -c 'umask 22; (umask 0); umask' We should also document this in the autoconf manual. Has it been reported? Seems like the kind of thing that could be fixed before Solaris 11 is released. http://defect.opensolaris.org/ Peter -- Peter O'Gorman http://pogma.com
Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)
Peter O'Gorman [EMAIL PROTECTED] wrote: Eric Blake wrote: According to Jim Meyering on 9/16/2008 3:58 AM: Jim Meyering [EMAIL PROTECTED] wrote: I discovered that Solaris 11's /bin/sh exhibits the following surprising behavior: $ /bin/sh -c 'umask 22; (umask 0); umask' We should also document this in the autoconf manual. Has it been reported? Seems like the kind of thing that could be fixed before Solaris 11 is released. http://defect.opensolaris.org/ Thanks for the link. I've just filed a report: http://defect.opensolaris.org/bz/show_bug.cgi?id=3450
Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)
Jim Meyering wrote: Peter O'Gorman [EMAIL PROTECTED] wrote: Eric Blake wrote: According to Jim Meyering on 9/16/2008 3:58 AM: Jim Meyering [EMAIL PROTECTED] wrote: I discovered that Solaris 11's /bin/sh exhibits the following surprising behavior: $ /bin/sh -c 'umask 22; (umask 0); umask' We should also document this in the autoconf manual. Has it been reported? Seems like the kind of thing that could be fixed before Solaris 11 is released. http://defect.opensolaris.org/ Thanks for the link. I've just filed a report: http://defect.opensolaris.org/bz/show_bug.cgi?id=3450 Ugh, I should have tried it before telling you to report it: % uname -a SunOS XX 5.11 snv_91 i86pc i386 i86pc % /bin/sh -c 'umask 22; (umask 0); umask' 0022 Looks like this bug is already fixed somewhere between builds 86 and 91. Peter -- Peter O'Gorman http://pogma.com
vasnprintf(-0.0L) on Irix [was: snapshot in preparation for m4 1.4.12]
Bruno Haible bruno at clisp.org writes:
the system sprintf does not know how to print -0, so the result is
0.00 and lacks -. Does it make more sense to adjust the existing
gl_PRINTF_INFINITE_LONG_DOUBLE (which also tests for NaN) to add a test
for negative zero, or to add a new macro gl_PRINTF_ZERO_LONG_DOUBLE?
Based on this info, I would have recommended to add a separate test to
m4/printf.m4, for clarity; however, in vasnprintf.m4 there are enough
#ifdefs, therefore I would simply have defined
NEED_PRINTF_INFINITE_LONG_DOUBLE.
At any rate, the Irix box also failed the infinite long double test, so it
already has problem with inf and/or NaN, and the place to add code for
-0.0 should be relatively easy to locate.
In this situation, m4/printf.m4 needs no changes at all. Find here a
proposed fix:
Bruno
--- lib/vasnprintf.c.orig 2008-09-13 19:02:12.0 +0200
+++ lib/vasnprintf.c 2008-09-13 19:01:42.0 +0200
@@ -255,11 +255,11 @@
#if NEED_PRINTF_INFINITE_LONG_DOUBLE !NEED_PRINTF_LONG_DOUBLE !defined
IN_LIBINTL
-/* Equivalent to !isfinite(x), but does not require libm. */
+/* Equivalent to !isfinite(x) || x == 0, but does not require libm. */
Close, but without the rest of the patch, this triggered an abort in
vasnprintf. However, with both pieces in place, I've tested that Irix 5.3
passes the testsuite. So here's what I'm pushing:
From: Eric Blake [EMAIL PROTECTED]
Date: Tue, 16 Sep 2008 09:36:24 -0600
Subject: [PATCH] vasnprintf: support Irix 5.3
* lib/vasnprintf.c (VASNPRINTF): Also handle -0.0L on platforms
that mishandle long double infinity.
Reported by Tom G. Christensen.
Signed-off-by: Eric Blake [EMAIL PROTECTED]
---
ChangeLog|8 +++
lib/vasnprintf.c | 61 -
2 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 86939ec..47fbf01 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,12 @@
2008-09-16 Bruno Haible [EMAIL PROTECTED]
+ and Eric Blake [EMAIL PROTECTED]
+
+ vasnprintf: support Irix 5.3
+ * lib/vasnprintf.c (VASNPRINTF): Also handle -0.0L on platforms
+ that mishandle long double infinity.
+ Reported by Tom G. Christensen.
+
+2008-09-16 Bruno Haible [EMAIL PROTECTED]
* doc/glibc-functions/scandir.texi: Mention the function is missing on
Solaris 9.
diff --git a/lib/vasnprintf.c b/lib/vasnprintf.c
index 4ddf45f..ace8933 100644
--- a/lib/vasnprintf.c
+++ b/lib/vasnprintf.c
@@ -255,11 +255,11 @@ is_infinite_or_zero (double x)
#if NEED_PRINTF_INFINITE_LONG_DOUBLE !NEED_PRINTF_LONG_DOUBLE !defined
IN_LIBINTL
-/* Equivalent to !isfinite(x), but does not require libm. */
+/* Equivalent to !isfinite(x) || x == 0, but does not require libm. */
static int
-is_infinitel (long double x)
+is_infinite_or_zerol (long double x)
{
- return isnanl (x) || (x + x == x x != 0.0L);
+ return isnanl (x) || x + x == x;
}
#endif
@@ -2578,8 +2578,10 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
# elif NEED_PRINTF_INFINITE_LONG_DOUBLE
|| (a.arg[dp-arg_index].type == TYPE_LONGDOUBLE
/* Some systems produce wrong output for Inf,
- -Inf, and NaN. */
- is_infinitel (a.arg[dp-
arg_index].a.a_longdouble))
+ -Inf, and NaN. Some systems in this category
+ (IRIX 5.3) also do so for -0.0. Therefore we
+ treat this case here as well. */
+ is_infinite_or_zerol (a.arg[dp-
arg_index].a.a_longdouble))
# endif
))
{
@@ -3139,7 +3141,54 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
abort ();
# else
/* arg is finite. */
- abort ();
+ if (!(arg == 0.0L))
+ abort ();
+
+ pad_ptr = p;
+
+ if (dp-conversion == 'f' || dp-conversion == 'F')
+ {
+ *p++ = '0';
+ if ((flags FLAG_ALT) || precision 0)
+ {
+ *p++ = decimal_point_char ();
+ for (; precision 0; precision--)
+ *p++ = '0';
+ }
+ }
+ else if (dp-conversion == 'e' || dp-conversion
== 'E')
+ {
+ *p++ = '0';
+ if ((flags FLAG_ALT) || precision 0)
+ {
+ *p++ = decimal_point_char ();
+
c-stack and Irix
I've finally figured out why c-stack is being finicky on Irix 5.3 [1]. POSIX requires that sigaltstack be given ss_sp pointing to the smallest address in the alternate stack. But Irix is non-compliant, and treats ss_sp as the starting address of the stack (which, since it grows down, makes it the largest address in the stack). From their man page for sigaltstack: The stack grows downward from high to lower addresses. The following code fragment is typically used to allocate an alternate stack. if ((sigstk.ss_sp = (char *)malloc(SIGSTKSZ)) == NULL) /* error return */; sigstk.ss_sp += SIGSTKSZ - 1; /* adjust ss_sp to point to base of stack */ sigstk.ss_size = SIGSTKSZ; This explains why Tom and I were having such a hard time in debugging c-stack code - the stack overflow handler was often triggering a secondary SIGSEGV as it traversed outside the bounds of the alternate stack, because we were setting up the alternate stack with the wrong bound per Irix conventions. Before m4 was converted over to use c-stack, m4's stackovf.c worked around this issue by allocating 2*SIGSTKSZ bytes, then passing the midway point of the overallocation to sigaltstack, compared to c-stack's current approach of just allocating SIGSTKSZ bytes. I'm debating about using the same workaround, or whether it is worth trying to write a configure-time test that checks for which side of the alternate stack is visited first in order add #ifdefs to set ss_sp correctly and avoid allocating the extra SIGSTKSZ bytes. Any preferences? Bruno, this means that libsigsegv 2.6 is buggy in handling sigsegv on platforms like Irix 5.3 (even though the tests currently pass, it is by sheer luck, because you are corrupting the contents of the stack outside of the area reserved for your stack-allocated alternate stack). Maybe you should make the stackoverflow1.c test be more robust, by allocating some stack variables on either side of the alternate stack, setting them to known patterns, and checking that they have not been corrupted when longjmp'ing back out of the overflow handler. Or maybe add a test that mmap's the alternate stack, such that exceeding the bounds of the alternate stack will indeed cause a definite segv, rather than a luck-of-the-draw clobbering of unrelated but allocated memory. [1] http://lists.gnu.org/archive/html/bug-m4/2008-09/msg00014.html -- Eric Blake
