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