From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: bug#25463: guile-2.0.13 Check errors Date: Mon, 06 Mar 2017 23:53:29 +0100 Message-ID: <87h9366mqe.fsf@gnu.org> References: <4f693f6528e76a93e17e73450e2bc320@openmailbox.org> <87vasg1luf.fsf@gnu.org> <675c7503-e8ca-3e6d-b7ff-fe82bbfa0d37@gmail.com> <874lz6s8d1.fsf@gnu.org> <09ad9e2c-0317-7fdb-97bd-97351dddcd86@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cl1Vh-0003zA-KT for guix-devel@gnu.org; Mon, 06 Mar 2017 17:53:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cl1Ve-0004Pc-Cd for guix-devel@gnu.org; Mon, 06 Mar 2017 17:53:45 -0500 In-Reply-To: <09ad9e2c-0317-7fdb-97bd-97351dddcd86@gmail.com> (Manolis Ragkousis's message of "Mon, 6 Mar 2017 18:45:41 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Manolis Ragkousis Cc: guix-devel@gnu.org, rennes@openmailbox.org, 25463@debbugs.gnu.org Manolis Ragkousis skribis: > Hello Ludo, welcome back! > > On 03/06/2017 06:00 PM, Ludovic Court=C3=A8s wrote: > >> Is it 100% reproducible if you run: >>=20 >> ./check-guile 00-repl-server.test >>=20 >> from Guile=E2=80=99s build tree? >>=20 >> 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. >>=20 >> 00-socket.test also uses Unix-domain sockets. Does it pass? >>=20 >> Looking more closely, it might be that one of the hunks of the patch >> below solves the problem. Could you try and report back? >>=20 >> (Looking at >> , I >> think ECONNRESET is more appropriate than ENOTCONN in the second case.) >>=20 >> HTH, >> Ludo=E2=80=99. >>=20 > > 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 =3D 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 =3D 42\n= ") Hmm! > I am testing with "GUILE_LOAD_PATH=3D. ./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) =3D 0=20 > 169<--197(pid5107)->io_write ("guile: ./pthread/pt-create.c:186: __pthr= ead_create_internal: Assertion `({ mach_" -1) =3D 0 225 This is the problem. =E2=86=91 > 100<--196(pid5107)->dir_lookup ("servers/crash" 0 0) =3D 0 1 "" 207<= --202(pid5107) > task192(pid5107)->mach_port_mod_refs (pn{ 10} 0 1) =3D 0=20 > 77<--147(pid5107)->dir_mkfile (18 384) =3D 0 220<--210(pid5107) > 207<--202(pid5107)->crash_dump_task ( task192(pid5107) 220<--210(pid= 5107) 4 0 0 2 13 0 118<--281(pid5107)) ...238 It leads to a core dump=E2=80=A6 > task133(pid5084)->mach_port_destroy (pn{ 49}) =3D 0=20 > 238... =3D 0=20 > 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... =3D 0 1 "" 192<--221(pid5084) > 167... =3D 0=20 > 192<--221(pid5084)->ifsock_getsockaddr () =3D 0 280<--220(pid5084) > task133(pid5084)->mach_port_deallocate (pn{ 49}) =3D 0=20 > 287<--266(pid5084)->socket_connect ( 280<--220(pid5084)) =3D 0x400000= 3d (Connection refused)=20 =E2=80=A6 and subsequent connection attempts fail, hence =E2=80=9Cunresolve= d=E2=80=9D test cases I think. Could you report the assertion failure to the Hurd folks? Thanks for investigating! Ludo=E2=80=99.