Subject: Re: bug#25463: guile-2.0.13 Check errors

From: Manolis Ragkousis <[email-masked]>
Date: Mon, 6 Mar 2017 18:45:41 +0200

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