bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [diffutils-3.0] 9 of 78 tests failed on Haiku


From: scott mc
Subject: Re: [diffutils-3.0] 9 of 78 tests failed on Haiku
Date: Fri, 8 Oct 2010 13:03:08 -0700

I have verified the sleep( ) issue and have checked with some of the
Haiku devs on these issues.  All of these are issues with Haiku.  I
have opened a handful of tickets in Haiku's trac to cover them:

http://dev.haiku-os.org/ticket/6704
http://dev.haiku-os.org/ticket/6705
http://dev.haiku-os.org/ticket/6706
http://dev.haiku-os.org/ticket/6707

I suspect the wc issues will also get addressed soon, they just hadn't
gotten to them yet.
Thanks for reviewing the results and getting back.
-scottmc



On Thu, Oct 7, 2010 at 7:36 AM, Bruno Haible <address@hidden> wrote:
> [dropped bug-diffutils from CC]
>
>> > Haiku, like BeOS have O_BINARY and O_TEXT but they have no effect:
>> > http://www.mail-archive.com/address@hidden/msg12137.html
>
> Yes, and gnulib's binary-io.h undefines O_BINARY and O_TEXT on Haiku for this
> reason.
>
>> > --- diffutils-3.0/gnulib-tests/test-dup2.c  2010-04-15 13:42:07.036700160 
>> > +0000
>> > +++ diffutils-3.0-haiku/gnulib-tests/test-dup2.c    2010-10-06
>> > 11:17:38.000000000 +0000
>> > @@ -176,6 +176,7 @@
>> >
>> >    /* On systems that distinguish between text and binary mode, dup2
>> >       reuses the mode of the source.  */
>> > +#if O_BINARY
>> >    setmode (fd, O_BINARY);
>> >    ASSERT (is_mode (fd, O_BINARY));
>> >    ASSERT (dup2 (fd, fd + 1) == fd + 1);
>> > @@ -190,6 +191,6 @@
>> >    ASSERT (close (fd + 1) == 0);
>> >    ASSERT (close (fd) == 0);
>> >    ASSERT (unlink (file) == 0);
>> > -
>> > +#endif
>> >    return 0;
>> >  }
>> > --- diffutils-3.0/gnulib-tests/test-fcntl.c 2010-04-15 13:42:08.027787264 
>> > +0000
>> > +++ diffutils-3.0-haiku/gnulib-tests/test-fcntl.c   2010-10-06
>> > 11:21:54.000000000 +0000
>> > @@ -298,6 +298,7 @@
>> >    ASSERT (is_mode (fd + 2, O_BINARY));
>> >    ASSERT (close (fd) == 0);
>> >
>> > +#if O_TEXT
>> >    setmode (fd + 2, O_TEXT);
>> >    ASSERT (fcntl (fd + 2, F_DUPFD, fd + 1) == fd + 1);
>> >    ASSERT (!is_open (fd));
>> > @@ -318,7 +319,7 @@
>> >    ASSERT (is_mode (fd, O_TEXT));
>> >    ASSERT (is_mode (fd + 2, O_TEXT));
>> >    ASSERT (close (fd + 2) == 0);
>> > -
>> > +#endif
>> >    /* Test F_GETFD.  */
>> >    errno = 0;
>> >    ASSERT (fcntl (-1, F_GETFD) == -1);
>
> Why do you need this? These two test files include "binary-io.h", which
> undefines O_BINARY and O_TEXT, and then setmode gets defined to a function
> that returns 0.
>
> Can you show the errors that you got and the preprocessed ("gcc -E") source
> code of one of these test files?
>
>> > Also on Haiku and BeOS SIGSEGV is the same as SIGBUS:
>> > http://dev.haiku-os.org/browser/haiku/trunk/headers/posix/signal.h (line 
>> > 132)
>
>> > diff -urN diffutils-3.0/gnulib-tests/test-signal.c
>> > diffutils-3.0-haiku/gnulib-tests/test-signal.c
>> > --- diffutils-3.0/gnulib-tests/test-signal.c        2010-04-15 
>> > 13:42:09.030932992 +0000
>> > +++ diffutils-3.0-haiku/gnulib-tests/test-signal.c  2010-10-06
>> > 11:28:31.000000000 +0000
>> > @@ -58,7 +58,7 @@
>> >  #ifdef SIGALRM
>> >      case SIGALRM:
>> >  #endif
>> > -#ifdef SIGBUS
>> > +#if defined SIGBUS && !defined(__HAIKU__)
>> >      case SIGBUS:
>> >  #endif
>> >  #ifdef SIGCHLD
>
> This is a bug in Haiku. Programs are supposed to be able to set different
> signal handlers for each signal, which implies that SIGBUS and SIGSEGV must
> be different.
>
>> > 9 of 78 tests failed.  (11 tests were not run).
>
>> > FAIL: test-btowc1.sh (exit: 134)
>> > ================================
>> >
>> > test-btowc.c:52: assertion failed
>> > Abort
>> > ./test-btowc1.sh: line 15: 431880 Abort
>> > LC_ALL=$LOCALE_FR ./test-btowc${EXEEXT} 1
>
> Can you show the value of LOCALE_FR in config.status? m4/locale-fr.m4
> contains a test program that verifies that LOCALE_FR gets set to a
> locale with ISO-8859-1 or ISO-8859-15 encoding. But the test program
> test-btowc.c then appears to encounter an encoding different from
> ISO-8859-1 and ISO-8859-15.
>
>> > FAIL: test-mbrtowc1.sh (exit: 134)
>> > ==================================
>> >
>> > test-mbrtowc.c:143: assertion failed
>> > Abort
>> > ./test-mbrtowc1.sh: line 15: 432356 Abort
>> > LC_ALL=$LOCALE_FR ./test-mbrtowc${EXEEXT} 1
>
> This could be due to an incorrect value of LOCALE_FR, see above.
>
>> > FAIL: test-mbsrtowcs1.sh (exit: 134)
>> > ====================================
>> >
>> > test-mbsrtowcs.c:111: assertion failed
>> > Abort
>> > ./test-mbsrtowcs1.sh: line 15: 432436 Abort
>> > LC_ALL=$LOCALE_FR ./test-mbsrtowcs${EXEEXT} 1
>
> Likewise.
>
>> > FAIL: test-wcrtomb.sh (exit: 1)
>> > ===============================
>> >
>> > test-wcrtomb.c:45: assertion failed
>> > Abort
>> > ./test-wcrtomb.sh: line 9: 433242 Abort
>> > LC_ALL=$LOCALE_FR ./test-wcrtomb${EXEEXT} 1
>
> Likewise.
>
>> > FAIL: test-c-stack.sh (exit: 1)
>> > ===============================
>> >
>> > ./test-c-stack.sh: line 7: 431920 Segmentation violation
>> > ./test-c-stack${EXEEXT} 2> t-c-stack.tmp
>
> Is the program crashing by NULL dereference or by stack overflow?
> Why is the c-stack module not working?
>
>> > FAIL: test-fcntl (exit: 134)
>> > ============================
>> >
>> > test-fcntl.c:261: assertion failed
>> > Abort
>
> What is the errno value that you get there, at test-fcntl.c:261?
>
>> > FAIL: test-sleep (exit: 134)
>> > ============================
>> >
>> > test-sleep.c:55: assertion failed
>> > Abort
>
> Is the sleep function provided by Haiku or by gnulib?
> If by Haiku, then it appears to have a wrong return value.
>
>> > FAIL: test-unsetenv (exit: 134)
>> > ===============================
>> >
>> > test-unsetenv.c:44: assertion failed
>> > Abort
>
> Bug in Haiku: unsetenv("a") does not remove all settings of the environment
> variable "a" from the environment.
>
>> > FAIL: test-wcwidth (exit: 134)
>> > ==============================
>> >
>> > test-wcwidth.c:57: assertion failed
>> > Abort
>
> Bug in Haiku: wcwidth (0x05B0) should be 0.
>
> Since Haiku is in active development, I'm not going to add workarounds to
> gnulib. Rather, the Haiku community should fix the bugs that are on Haiku's
> side.
>
> Bruno
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]