GNU bug report logs - #25463
test failures on GNU/Hurd (2.0.13)

Previous Next

To reply to this bug, email your comments to 25463 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: rennes <at> openmailbox.org
To: bug-guile <at> gnu.org
Cc: guix-devel <at> gnu.org, manolis837 <at> gmail.com
Subject: guile-2.0.13 Check errors
Date: Mon, 16 Jan 2017 19:25:35 -0600

[Message part 1 (text/plain, inline)]

Hello,

I am trying to build guile version 2.0.13 in GNU Hurd through Guix 
package manager, in the 'Check' phase I have 4 errors; I am attaching 
the build log(config.zip), environment variables(environment-variables) 
and test log(check-guile.zip).

This is a grep of errors, any idea how I can deal with this?

/*---------------------------------------------------------------------------------*/
ERROR: 00-repl-server.test: repl-server: simple expression - arguments: 
((system-error "fport_fill_input" "~A" ("Transport endpoint is not 
connected") (1073741881)))
ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint 
is not connected") (1073741881)))

ERROR: statprof.test: return values - arguments: ((system-error 
"setitimer" "~A" ("Function not implemented") (1073741902)))
ERROR: statprof.test: statistical sample counts within expected range - 
arguments: ((misc-error #f "~A" ("Can't reset profiler while profiler is 
running.") #f))
ERROR: statprof.test: accurate call counting - arguments: ((misc-error 
#f "~A" ("Can't reset profiler while profiler is running.") #f))
/*---------------------------------------------------------------------------------*/

System details:

Guix version: guix (GNU Guix) 0.11.0
Hurd version: Debian/GNU Hurd 0.9 GNU-Mach 1.8+git20170102-486/Hurd-0.9 
i686-AT386 GNU

Thanks

[check-guile.zip (application/zip, attachment)]

[config.zip (application/zip, attachment)]

[environment-variables (text/plain, attachment)]

Message #10 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: rennes <at> openmailbox.org
Cc: guix-devel <at> gnu.org, manolis837 <at> gmail.com, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Sat, 11 Feb 2017 22:03:36 +0100

Hello!

rennes <at> openmailbox.org skribis:

> I am trying to build guile version 2.0.13 in GNU Hurd through Guix
> package manager, in the 'Check' phase I have 4 errors; I am attaching
> the build log(config.zip), environment
> variables(environment-variables) and test log(check-guile.zip).
>
> This is a grep of errors, any idea how I can deal with this?
>
> /*---------------------------------------------------------------------------------*/
> ERROR: 00-repl-server.test: repl-server: simple expression -
> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
> is not connected") (1073741881)))
> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
> is not connected") (1073741881)))

The Guix package for Guile incorporates a patch that corresponds to
Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
race condition for these tests.

Could you check that this patch is really being used?

> ERROR: statprof.test: return values - arguments: ((system-error
> "setitimer" "~A" ("Function not implemented") (1073741902)))
> ERROR: statprof.test: statistical sample counts within expected range
> - 
> arguments: ((misc-error #f "~A" ("Can't reset profiler while profiler
> is running.") #f))
> ERROR: statprof.test: accurate call counting - arguments: ((misc-error
> #f "~A" ("Can't reset profiler while profiler is running.") #f))

This file uses a ‘when-implemented’ macro to skip tests upon ENOSYS
(“Function not implemented”).

The first of these 3 tests lacked it though, so I’ve added it in commit
f2764cb1031379c47a17c02fef3f8164a6ce9cda.

Could you run these tests manually to see what’s going on?  From the
top-level build tree of Guile, run:

  ./check-guile statprof.test

and see if it fails similarly.  If it does, you can add ‘display’ or
‘pk’ calls in the tests to see what’s going on.

HTH!

Ludo’.

Message #13 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: Manolis Ragkousis <manolis837 <at> gmail.com>
To: rennes <at> openmailbox.org
Cc: guix-devel <at> gnu.org, ludo <at> gnu.org, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Sun, 12 Feb 2017 15:44:36 +0200

Hello Renes,

On 02/12/17 10:37, rennes <at> openmailbox.org wrote:
> Now the following error is left:
> --------------------------------------------
> Running time.test
> FAIL: time.test: internal-time-units-per-second: versus times and sleep
> Running tree-il.test
> 
> Totals for this test run:
> passes:                 39537
> failures:               1
> unexpected passes:      0
> expected failures:      9
> unresolved test cases:  582
> untested test cases:    1
> unsupported test cases: 10
> errors:                 0
> --------------------------------------------
> 

Locally on Hurd I am using this patch
http://paste.lisp.org/display/338954 on the glibc/hurd package to work
around that test failure. Ideally we need to modify the way guile
handles time.[1]

Manolis


[1]
https://lists.gnu.org/archive/html/bug-hurd/2015-10/msg00019.html

Message #16 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: rennes <at> openmailbox.org
To: ludo <at> gnu.org
Cc: guix-devel <at> gnu.org, manolis837 <at> gmail.com, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Sun, 12 Feb 2017 02:37:44 -0600

[Message part 1 (text/plain, inline)]

Hi,

> The Guix package for Guile incorporates a patch that corresponds to
> Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
> race condition for these tests.
> 
> Could you check that this patch is really being used?

The patch is working.

>> ERROR: statprof.test: return values - arguments: ((system-error
>> "setitimer" "~A" ("Function not implemented") (1073741902)))
>> ERROR: statprof.test: statistical sample counts within expected range
>> -
>> arguments: ((misc-error #f "~A" ("Can't reset profiler while profiler
>> is running.") #f))
>> ERROR: statprof.test: accurate call counting - arguments: ((misc-error
>> #f "~A" ("Can't reset profiler while profiler is running.") #f))
> 
> This file uses a ‘when-implemented’ macro to skip tests upon ENOSYS
> (“Function not implemented”).
> 
> The first of these 3 tests lacked it though, so I’ve added it in commit
> f2764cb1031379c47a17c02fef3f8164a6ce9cda.

whith this commit resolve 'statprof.test' test!

Now the following error is left:
--------------------------------------------
Running time.test
FAIL: time.test: internal-time-units-per-second: versus times and sleep
Running tree-il.test

Totals for this test run:
passes:                 39537
failures:               1
unexpected passes:      0
expected failures:      9
unresolved test cases:  582
untested test cases:    1
unsupported test cases: 10
errors:                 0
--------------------------------------------

Attached logs.
Regards

[check-guile.log (text/plain, attachment)]

[config.log (text/plain, attachment)]

[environment-variables (text/plain, attachment)]

Message #19 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Manolis Ragkousis <manolis837 <at> gmail.com>
Cc: guix-devel <at> gnu.org, rennes <at> openmailbox.org,
 Richard Braun <rbraun <at> sceen.net>, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Sun, 12 Feb 2017 22:18:02 +0100

Hello!

Manolis Ragkousis <manolis837 <at> gmail.com> skribis:

> Locally on Hurd I am using this patch
> http://paste.lisp.org/display/338954 on the glibc/hurd package to work
> around that test failure. Ideally we need to modify the way guile
> handles time.[1]

Does ‘glibc/hurd’ have this patch in ‘core-updates’?  Should it?

Would it make sense to address this issue in Guile instead of libc,
Richard?  I guess the answer depends on how many programs make this
assumption besides Guile.

Thanks,
Ludo’.

Message #22 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: Richard Braun <rbraun <at> sceen.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, rennes <at> openmailbox.org,
 Manolis Ragkousis <manolis837 <at> gmail.com>, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Mon, 13 Feb 2017 10:47:51 +0100

On Sun, Feb 12, 2017 at 10:18:02PM +0100, Ludovic Courtès wrote:
> Manolis Ragkousis <manolis837 <at> gmail.com> skribis:
> 
> > Locally on Hurd I am using this patch
> > http://paste.lisp.org/display/338954 on the glibc/hurd package to work
> > around that test failure. Ideally we need to modify the way guile
> > handles time.[1]
> 
> Does ‘glibc/hurd’ have this patch in ‘core-updates’?  Should it?
> 
> Would it make sense to address this issue in Guile instead of libc,
> Richard?  I guess the answer depends on how many programs make this
> assumption besides Guile.

I'd say applications shouldn't be concerned with that, this problem
should remain solved by the system components, and libc (or procfs or
whatever) are the right places to deal with it.

See https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00089.html.

-- 
Richard Braun

Message #25 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: Manolis Ragkousis <manolis837 <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, rennes <at> openmailbox.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Sun, 19 Feb 2017 17:53:11 +0200

[Message part 1 (text/plain, inline)]

Hello,

On 02/11/2017 11:03 PM, Ludovic Courtès wrote:
> Hello!
> 
> rennes <at> openmailbox.org skribis:
> 
>> I am trying to build guile version 2.0.13 in GNU Hurd through Guix
>> package manager, in the 'Check' phase I have 4 errors; I am attaching
>> the build log(config.zip), environment
>> variables(environment-variables) and test log(check-guile.zip).
>>
>> This is a grep of errors, any idea how I can deal with this?
>>
>> /*---------------------------------------------------------------------------------*/
>> ERROR: 00-repl-server.test: repl-server: simple expression -
>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>> is not connected") (1073741881)))
>> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>> is not connected") (1073741881)))
> 
> The Guix package for Guile incorporates a patch that corresponds to
> Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
> race condition for these tests.
> 

While using guile 2.0.14, which has commit 2fbde7f02adb8c6, the bug is
still present. Any ideas on what could be causing this Ludo?

Manolis

[environment-variables (text/plain, attachment)]

Message #28 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Manolis Ragkousis <manolis837 <at> gmail.com>
Cc: guix-devel <at> gnu.org, rennes <at> openmailbox.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Mon, 06 Mar 2017 17:00:42 +0100

[Message part 1 (text/plain, inline)]

Hi Manolis,

Manolis Ragkousis <manolis837 <at> gmail.com> skribis:

> On 02/11/2017 11:03 PM, Ludovic Courtès wrote:
>> Hello!
>> 
>> rennes <at> openmailbox.org skribis:
>> 
>>> I am trying to build guile version 2.0.13 in GNU Hurd through Guix
>>> package manager, in the 'Check' phase I have 4 errors; I am attaching
>>> the build log(config.zip), environment
>>> variables(environment-variables) and test log(check-guile.zip).
>>>
>>> This is a grep of errors, any idea how I can deal with this?
>>>
>>> /*---------------------------------------------------------------------------------*/
>>> ERROR: 00-repl-server.test: repl-server: simple expression -
>>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>>> is not connected") (1073741881)))
>>> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
>>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>>> is not connected") (1073741881)))
>> 
>> The Guix package for Guile incorporates a patch that corresponds to
>> Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
>> race condition for these tests.
>> 
>
> While using guile 2.0.14, which has commit 2fbde7f02adb8c6, the bug is
> still present. Any ideas on what could be causing this Ludo?

Is it 100% reproducible if you run:

  ./check-guile 00-repl-server.test

from Guile’s build tree?

This test uses a Unix-domain socket, which on the Hurd means that
/servers/socket/3 (I think?) must have the right translator on it.

00-socket.test also uses Unix-domain sockets.  Does it pass?

Looking more closely, it might be that one of the hunks of the patch
below solves the problem.  Could you try and report back?

(Looking at
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html>, I
think ECONNRESET is more appropriate than ENOTCONN in the second case.)

HTH,
Ludo’.

[Message part 2 (text/x-patch, inline)]

diff --git a/test-suite/tests/00-repl-server.test b/test-suite/tests/00-repl-server.test
index 4b5ec0cb3..0b4d0c6b0 100644
--- a/test-suite/tests/00-repl-server.test
+++ b/test-suite/tests/00-repl-server.test
@@ -62,7 +62,7 @@ socket connected to that server."
                  (connect client-socket sockaddr))
                (lambda args
                  (when (memv (system-error-errno args)
-                             (list ENOENT ECONNREFUSED))
+                             (list ENOENT ECONNREFUSED ENOTCONN))
                    (when (> tries 30)
                      (throw 'unresolved))
                    (usleep 100)
@@ -139,7 +139,7 @@ reached."
                   (loop (+ 1 n))))))
         (lambda args
           (->bool (memv (system-error-errno args)
-                        (list ECONNRESET EPIPE))))))))
+                        (list ECONNRESET EPIPE ENOTCONN))))))))
 
 ;;; Local Variables:
 ;;; eval: (put 'with-repl-server 'scheme-indent-function 1)

Message #31 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: Manolis Ragkousis <manolis837 <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, rennes <at> openmailbox.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Mon, 6 Mar 2017 18:45:41 +0200

[Message part 1 (text/plain, inline)]

Hello Ludo, welcome back!

On 03/06/2017 06:00 PM, Ludovic Courtès wrote:

> Is it 100% reproducible if you run:
> 
>   ./check-guile 00-repl-server.test
> 
> from Guile’s build tree?
> 
> This test uses a Unix-domain socket, which on the Hurd means that
> /servers/socket/3 (I think?) must have the right translator on it.
> 
> 00-socket.test also uses Unix-domain sockets.  Does it pass?
> 
> Looking more closely, it might be that one of the hunks of the patch
> below solves the problem.  Could you try and report back?
> 
> (Looking at
> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html>, I
> think ECONNRESET is more appropriate than ENOTCONN in the second case.)
> 
> HTH,
> Ludo’.
> 

Since the last email I sent, I found out that I was getting ENOTCONN
only after the second time I was running the test, and every time after
that, unless I delete /tmp/repl-server.

The error you get the first time you run the test is

FAIL: 00-repl-server.test: repl-server: simple expression - arguments:
(expected-value "scheme@(repl-server)> $1 = 42\n" actual-value
"scheme@(repl-server)> While reading expression:\nERROR: In procedure
fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily unavailable\n$1 = 42\n")

I am testing with "GUILE_LOAD_PATH=. ./guile-test
tests/00-initial-env.test tests/00-repl-server.test" and it's 100%
reproducible if you delete /tmp/repl-server after each run.
00-socket.test passes each time successfully. Your patch doesn't solve
the first error.

Trying to debug the problem using rpctrace causes both tests to end with
unresolved test cases. I am attaching the rpc-trace output.

Manolis

[rpc-trace.txt (text/plain, attachment)]

Message #34 received at 25463 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Manolis Ragkousis <manolis837 <at> gmail.com>
Cc: guix-devel <at> gnu.org, rennes <at> openmailbox.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>, 25463 <at> debbugs.gnu.org
Subject: Re: bug#25463: guile-2.0.13 Check errors
Date: Mon, 06 Mar 2017 23:53:29 +0100

Manolis Ragkousis <manolis837 <at> gmail.com> skribis:

> Hello Ludo, welcome back!
>
> On 03/06/2017 06:00 PM, Ludovic Courtès wrote:
>
>> Is it 100% reproducible if you run:
>> 
>>   ./check-guile 00-repl-server.test
>> 
>> from Guile’s build tree?
>> 
>> This test uses a Unix-domain socket, which on the Hurd means that
>> /servers/socket/3 (I think?) must have the right translator on it.
>> 
>> 00-socket.test also uses Unix-domain sockets.  Does it pass?
>> 
>> Looking more closely, it might be that one of the hunks of the patch
>> below solves the problem.  Could you try and report back?
>> 
>> (Looking at
>> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html>, I
>> think ECONNRESET is more appropriate than ENOTCONN in the second case.)
>> 
>> HTH,
>> Ludo’.
>> 
>
> Since the last email I sent, I found out that I was getting ENOTCONN
> only after the second time I was running the test, and every time after
> that, unless I delete /tmp/repl-server.

Oh, interesting.

> The error you get the first time you run the test is
>
> FAIL: 00-repl-server.test: repl-server: simple expression - arguments:
> (expected-value "scheme@(repl-server)> $1 = 42\n" actual-value
> "scheme@(repl-server)> While reading expression:\nERROR: In procedure
> fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily unavailable\n$1 = 42\n")

Hmm!

> I am testing with "GUILE_LOAD_PATH=. ./guile-test

You mean ./check-guile, right?

> tests/00-initial-env.test tests/00-repl-server.test" and it's 100%
> reproducible if you delete /tmp/repl-server after each run.
> 00-socket.test passes each time successfully. Your patch doesn't solve
> the first error.

OK.

> Trying to debug the problem using rpctrace causes both tests to end with
> unresolved test cases. I am attaching the rpc-trace output.

[...]

> task192(pid5107)->mach_port_mod_refs (pn{ 46} 1 -1) = 0 
>   169<--197(pid5107)->io_write ("guile: ./pthread/pt-create.c:186: __pthread_create_internal: Assertion `({ mach_" -1) = 0 225

This is the problem.  ↑

>   100<--196(pid5107)->dir_lookup ("servers/crash" 0 0) = 0 1 ""    207<--202(pid5107)
> task192(pid5107)->mach_port_mod_refs (pn{ 10} 0 1) = 0 
>   77<--147(pid5107)->dir_mkfile (18 384) = 0    220<--210(pid5107)
>   207<--202(pid5107)->crash_dump_task ( task192(pid5107)    220<--210(pid5107) 4 0 0 2 13 0    118<--281(pid5107)) ...238

It leads to a core dump…

> task133(pid5084)->mach_port_destroy (pn{ 49}) = 0 
> 238... = 0 
>   225<--265(pid-1)->msg_sig_post (20 1  task133(pid5084));
>   100<--250(pid5084)->dir_lookup ("tmp/repl-server" 0 0) ...238
> task133(pid5084)->mach_port_deallocate (pn{  1}) ...167
> 238... = 0 1 ""    192<--221(pid5084)
> 167... = 0 
>   192<--221(pid5084)->ifsock_getsockaddr () = 0    280<--220(pid5084)
> task133(pid5084)->mach_port_deallocate (pn{ 49}) = 0 
>   287<--266(pid5084)->socket_connect (   280<--220(pid5084)) = 0x4000003d (Connection refused) 

… and subsequent connection attempts fail, hence “unresolved” test cases
I think.

Could you report the assertion failure to the Hurd folks?

Thanks for investigating!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.