From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: emacstheviking Newsgroups: gmane.lisp.guile.bugs Subject: bug#22095: FATAL: Cannot use remote repl server, possible dupe of bug#21993 ?? Date: Sat, 5 Dec 2015 00:31:02 +0000 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3c0287f981805261bbf96 X-Trace: ger.gmane.org 1449325275 1234 80.91.229.3 (5 Dec 2015 14:21:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Dec 2015 14:21:15 +0000 (UTC) To: 22095@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sat Dec 05 15:20:59 2015 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a5Dhq-0005eT-74 for guile-bugs@m.gmane.org; Sat, 05 Dec 2015 15:20:58 +0100 Original-Received: from localhost ([::1]:46684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5Dhp-0002ur-IH for guile-bugs@m.gmane.org; Sat, 05 Dec 2015 09:20:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a50pb-0007xT-2G for bug-guile@gnu.org; Fri, 04 Dec 2015 19:36:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a50pZ-0006h6-5p for bug-guile@gnu.org; Fri, 04 Dec 2015 19:36:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a50pZ-0006h2-2J for bug-guile@gnu.org; Fri, 04 Dec 2015 19:36:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a50pY-0005vq-9K for bug-guile@gnu.org; Fri, 04 Dec 2015 19:36:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: emacstheviking Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 05 Dec 2015 00:36:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 22095 X-GNU-PR-Package: guile X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.144927575222782 (code B ref -1); Sat, 05 Dec 2015 00:36:03 +0000 Original-Received: (at submit) by debbugs.gnu.org; 5 Dec 2015 00:35:52 +0000 Original-Received: from localhost ([127.0.0.1]:39519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a50pJ-0005vL-JE for submit@debbugs.gnu.org; Fri, 04 Dec 2015 19:35:50 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54110) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a50lS-0005pV-Hw for submit@debbugs.gnu.org; Fri, 04 Dec 2015 19:32:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a50lQ-0005r7-2Z for submit@debbugs.gnu.org; Fri, 04 Dec 2015 19:31:50 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:38724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a50lQ-0005r3-0Y for submit@debbugs.gnu.org; Fri, 04 Dec 2015 19:31:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a50lN-0007B1-Qq for bug-guile@gnu.org; Fri, 04 Dec 2015 19:31:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a50lL-0005pd-UT for bug-guile@gnu.org; Fri, 04 Dec 2015 19:31:45 -0500 Original-Received: from mail-lb0-x22e.google.com ([2a00:1450:4010:c04::22e]:35998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a50lL-0005pM-Ip for bug-guile@gnu.org; Fri, 04 Dec 2015 19:31:43 -0500 Original-Received: by lbblt2 with SMTP id lt2so29793544lbb.3 for ; Fri, 04 Dec 2015 16:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=8+y6bfNWWX5NTQiImAtHUPL5IrhdrO6r5octI9Pqeig=; b=Y+LiUMaEIb6lumPdaYrLFysI5IgFy+AaYNN1sdUt8EwBRGfZCShvkipFKNLDG1N21E 1P6rAJAr/TGvKTECYv2w42hSOo9dvCqL/8Atfa6daRhfwL12rg5HNOH5PfaMVA7si8jg pEhF9KocAK8NCagyVY6u0+CRmYl92j0t1YPFC9qdFutdjyY36oK3jqQEMnEqu9dXdR6u qvXPAvXMae3bZTDERTTTpAJvAa3r9qg2zAPkpHyjQs3SPQipCBdNfPLqFVzNE1LnmVol 4FpcJ20paJopytov2MMHk5mYlAawv6XUa39WM49rSE92CfaB2zeMIFaMlsnofxtQSgrq U6zA== X-Received: by 10.112.205.10 with SMTP id lc10mr8976763lbc.31.1449275502334; Fri, 04 Dec 2015 16:31:42 -0800 (PST) Original-Received: by 10.25.82.208 with HTTP; Fri, 4 Dec 2015 16:31:02 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Mailman-Approved-At: Fri, 04 Dec 2015 19:35:47 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-Mailman-Approved-At: Sat, 05 Dec 2015 09:20:22 -0500 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7911 Archived-At: --001a11c3c0287f981805261bbf96 Content-Type: text/plain; charset=UTF-8 Hi, This bug is possibly the same as: http://lists.gnu.org/archive/html/bug-guile/2015-11/msg00030.html I am using OS X as well, the same as the above report mentions, 10.11.1. I can only offer some additional information to the above report... it's a blocker for me. I have tried using both telnet and netcat with both TCP/IP and Unix domain sockets and the problem persists whichever is used. It happens both when --listen is used or if explicitly starred from the REPL using the server module functions. *Strangely I can still launch a REPL from emacs with "M-x run-geiser"* and specify "guile" as the scheme. I am assuming the geiser code uses "com-int" to do the dirty work at the bottom so it's interesting that it works but the REPL server per se doesn't work. I don't yet know why that should be the case. I enclose my trace of an attempt at using the default unix domains socket "/tmp/guile-socket" as stated in the source code. I am a seasoned C developer (30 years) but my socket knowledge is not that hot these days nor is my Scheme, something I decided to come back to and right now it feels terrible because of this! Bummer. If I can get a reliable build of guile from the sources I will attempt to put in some logging and tracing and actually see what the problem might be on OSX. There is probably some subtle socket default difference between it and Ubuntu; "bug#21993: REPL Servers broken on OSX" states the problem does not exist on that distro. In the file: module/system/repl/server.scm at line 127: ;; Put the socket into non-blocking mode. (fcntl server-socket F_SETFL (logior O_NONBLOCK (fcntl server-socket F_GETFL))) and I then refer you to this page: http://stackoverflow.com/questions/14370489/what-can-cause-a-resource-temporarily-unavailable-on-sock-send-command of which the essence is, from the send() man page: That's because you're using a non-blocking socket and the output buffer is full. When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-block- ing I/O mode. In non-blocking mode it would return EAGAIN in this case. The blowout seems to happen immediately the socket connects, that makes me think that the send buffer should be initially empty to the new client connection so I can only imagine that either something filled it really quick or there is some kind of edge case with socket options being managed slightly differently across platform stacks. Just a wild guess. Also worth a mention is this part of the trace, which may not mean anything but to me at least it is also noteworthy: scheme@(guile-user) [1]> Backtrace: In ice-9/boot-9.scm: 157: 13 [catch #t # ...] In unknown file: ?: 12 [apply-smob/1 #] What if there is some memory corruption with the SMOB on OSX which then fails and manifests as a socket failure??? That's pure speculation and without looking harder and deeper I really couldn't say. Gut feeling: It's just the spawned session bleeding out as the ice-9 stuff is the first thing loaded or something?! Many thanks I love Guile by the way, having used Gambit and Chicken in the past I decided to use GNU tools for my SDL2 application, I wanted to REPL in and hack the code while it was running... I will but this is in the way! All the very best, Hope it helps! Sean Charles. -- stack trace -- scheme@(guile-user)> (make-unix-domain-server-socket ) ;;; :1:0: warning: possibly unbound variable `make-unix-domain-server-socket' :1:0: In procedure #:1:0 ()>: :1:0: In procedure module-lookup: Unbound variable: make-unix-domain-server-socket Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> (use-modules (system repl server)) scheme@(guile-user) [1]> (make-unix-domain-server-socket ) $1 = # scheme@(guile-user) [1]> (spawn-server $1) $2 = # scheme@(guile-user) [1]> Backtrace: In ice-9/boot-9.scm: 157: 13 [catch #t # ...] In unknown file: ?: 12 [apply-smob/1 #] In ice-9/boot-9.scm: 157: 11 [catch #t # ...] In unknown file: ?: 10 [with-continuation-barrier #] In ice-9/boot-9.scm: 157: 9 [catch #t # ...] In unknown file: ?: 8 [apply-smob/1 #] In system/repl/server.scm: 164: 7 [#] In system/repl/repl.scm: 142: 6 [start-repl* scheme #f #] 168: 5 [run-repl* # #] 123: 4 [# system-error ...] In ice-9/format.scm: 1593: 3 [format # "While reading expression:\n"] 766: 2 [format:format-work "While reading expression:\n" ()] 81: 1 [anychar-dispatch] In unknown file: ?: 0 [write-char #\i #] ERROR: In procedure write-char: ERROR: In procedure fport_write: Broken pipe Backtrace: In ice-9/boot-9.scm: 157: 2 [catch #t # ...] In unknown file: ?: 1 [apply-smob/1 #] In ice-9/boot-9.scm: 157: 0 [catch #t # ...] ice-9/boot-9.scm:157:17: In procedure catch: ice-9/boot-9.scm:157:17: In procedure fport_write: Broken pipe --001a11c3c0287f981805261bbf96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This bug is possibly the same as: <= a href=3D"http://lists.gnu.org/archive/html/bug-guile/2015-11/msg00030.html= ">http://lists.gnu.org/archive/html/bug-guile/2015-11/msg00030.html

I am using OS X as well, the same as the above report= mentions, 10.11.1.
I can only offer some additional information = to the above report... it's a blocker for =C2=A0me.

I have tried using both telnet and netcat with both TCP/IP and Unix d= omain sockets and the problem persists whichever is used. It happens both w= hen --listen is used or if explicitly starred from the REPL using the serve= r module functions.

Strangely I can still launc= h a REPL from emacs with "M-x run-geiser" and specify "g= uile" as the scheme.

I am assuming the geiser= code uses "com-int" to do the dirty work at the bottom so it'= ;s interesting that it works but the REPL server per se doesn't work. I= don't yet know why that should be the case.

I= enclose my trace of an attempt at using the default unix domains socket &q= uot;/tmp/guile-socket" as stated in the source code.

I am a seasoned C developer (30 years) but my socket knowledge is n= ot that hot these days nor is my Scheme, something I decided to come back t= o and right now it feels terrible because of this! Bummer.
If I can get a reliable build of guile from the sources I will= attempt to put in some logging and tracing and actually see what the probl= em might be on OSX. There is probably some subtle socket default difference= between it and Ubuntu; =C2=A0 "bug#21993: REPL Servers broken on OSX&= quot; states the problem does not exist on that distro.

In the file: module/system/repl/server.scm at line 127:

=C2=A0 ;; Put the socket into non-blocking mode.
=C2=A0 (fcntl server-socket= F_SETFL
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(logior O_NONBLOCK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0(fcntl server-socket F_GETFL)))

and I then refer you to this page:
http://stackoverflow.com/questions/14370489/what-can= -cause-a-resource-temporarily-unavailable-on-sock-send-command

of which the essence is, from the send() man page:

That's because you're using a=C2=A0= non-blocking=C2=A0socket and the output buffer is full.

 When the message does not fit into  the  send  buffe=
r  of  the  socket,
   send() normally blocks, unless =
the socket has been placed in non-block-
   ing I/O mode.  In=
 non-blocking mode it  would  ret=
urn  EAGAIN  in  this
   case.
Th= e blowout seems to happen immediately the socket connects, that makes me th= ink that the send buffer should be initially empty to the new client connec= tion so I can only imagine that either something filled it really quick or = there is some kind of edge case with socket options being managed slightly = differently across platform stacks. Just a wild guess.

=
Also worth a mention is this part of the trace, which may not mean any= thing but to me at least it is also noteworthy:

scheme@(guile-user) [1]> Backtrac= e:
In ice-9/boot-9.scm= :
=C2=A0157: 13 [catch= #t #<catch-closure 109170c40> ...]
In unknown file:
=C2=A0 =C2=A0?: 12 [apply-smob/1 #<catch-closure 109170c4= 0>]

What if there is some memory c= orruption with the SMOB on OSX which then fails and manifests as a socket f= ailure??? That's pure speculation and without looking harder and deeper= I really couldn't say. Gut feeling: It's just the spawned session = bleeding out as the ice-9 stuff is the first thing loaded or something?!



Many thanks I love Gui= le by the way, having used Gambit and Chicken in the past I decided to use = GNU tools for my SDL2 application, I wanted to REPL in and hack the code wh= ile it was running... I will but this is in the way!

All the very best,
Hope it helps!

Sea= n Charles.

-- stack trace --

<= div>
scheme@(guile-user)> (make-unix-domain-server-socket )
;;; <stdin>:1:0: warning: possibly unbound variable `make-unix-doma= in-server-socket'
<unnamed port>:1:0: In procedure #<= ;procedure 10930e0c0 at <current input>:1:0 ()>:
<unn= amed port>:1:0: In procedure module-lookup: Unbound variable: make-unix-= domain-server-socket

Entering a new prompt.=C2=A0 = Type `,bt' for a backtrace or `,q' to continue.
scheme@(g= uile-user) [1]> (use-modules (system repl server))
scheme@(gui= le-user) [1]> (make-unix-domain-server-socket )
$1 =3D #<in= put-output: socket 9>
scheme@(guile-user) [1]> (spawn-serve= r $1)
$2 =3D #<thread 123145304985600 (10915ca00)>
scheme@(guile-user) [1]> Backtrace:
In ice-9/boot-9.scm:
=C2=A0157: 13 [catch #t #<catch-closure 109170c40> ...]
<= div>In unknown file:
=C2=A0 =C2=A0?: 12 [apply-smob/1 #<catch-= closure 109170c40>]
In ice-9/boot-9.scm:
=C2=A0157: = 11 [catch #t #<procedure 1092f4a20 at system/repl/server.scm:140:10 ()&g= t; ...]
In unknown file:
=C2=A0 =C2=A0?: 10 [with-conti= nuation-barrier #<procedure 109170540 at system/repl/server.scm:158:3 ()= >]
In ice-9/boot-9.scm:
=C2=A0157: 9 [catch #t #<= catch-closure 109170500> ...]
In unknown file:
=C2= =A0 =C2=A0?: 8 [apply-smob/1 #<catch-closure 109170500>]
In= system/repl/server.scm:
=C2=A0164: 7 [#<procedure 109170540 a= t system/repl/server.scm:158:3 ()>]
In system/repl/repl.scm:
=C2=A0142: 6 [start-repl* scheme #f #<procedure prompting-meta-= read (repl)>]
=C2=A0168: 5 [run-repl* # #<procedure prompti= ng-meta-read (repl)>]
=C2=A0123: 4 [#<procedure 108da0520 a= t system/repl/repl.scm:118:4 (key . args)> system-error ...]
I= n ice-9/format.scm:
1593: 3 [format #<input-output: socket 16&= gt; "While reading expression:\n"]
=C2=A0766: 2 [format= :format-work "While reading expression:\n" ()]
=C2=A0 8= 1: 1 [anychar-dispatch]
In unknown file:
=C2=A0 =C2=A0?= : 0 [write-char #\i #<input-output: socket 16>]

<= div>ERROR: In procedure write-char:
ERROR: In procedure fport_wri= te: Broken pipe
Backtrace:
In ice-9/boot-9.scm:
=C2=A0157: 2 [catch #t #<catch-closure 109170c40> ...]
I= n unknown file:
=C2=A0 =C2=A0?: 1 [apply-smob/1 #<catch-closur= e 109170c40>]
In ice-9/boot-9.scm:
=C2=A0157: 0 [cat= ch #t #<procedure 1092f4a20 at system/repl/server.scm:140:10 ()> ...]=

ice-9/boot-9.scm:157:17: In procedure catch:
ice-9/boot-9.scm:157:17: In procedure fport_write: Broken pipe
<= /div>


--001a11c3c0287f981805261bbf96--