Re: bug#25463: guile-2.0.13 Check errors

[ludo@gnu.org (Ludovic Courtès)]

Manolis Ragkousis <manolis837@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’.