Hi,
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:
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 #<catch-closure 109170c40> ...]
In unknown file:
?: 12 [apply-smob/1 #<catch-closure 109170c40>]
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 )
;;; <stdin>:1:0: warning: possibly unbound variable `make-unix-domain-server-socket'
<unnamed port>:1:0: In procedure #<procedure 10930e0c0 at <current input>:1:0 ()>:
<unnamed port>: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 = #<input-output: socket 9>
scheme@(guile-user) [1]> (spawn-server $1)
$2 = #<thread 123145304985600 (10915ca00)>
scheme@(guile-user) [1]> Backtrace:
In ice-9/boot-9.scm:
157: 13 [catch #t #<catch-closure 109170c40> ...]
In unknown file:
?: 12 [apply-smob/1 #<catch-closure 109170c40>]
In ice-9/boot-9.scm:
157: 11 [catch #t #<procedure 1092f4a20 at system/repl/server.scm:140:10 ()> ...]
In unknown file:
?: 10 [with-continuation-barrier #<procedure 109170540 at system/repl/server.scm:158:3 ()>]
In ice-9/boot-9.scm:
157: 9 [catch #t #<catch-closure 109170500> ...]
In unknown file:
?: 8 [apply-smob/1 #<catch-closure 109170500>]
In system/repl/server.scm:
164: 7 [#<procedure 109170540 at system/repl/server.scm:158:3 ()>]
In system/repl/repl.scm:
142: 6 [start-repl* scheme #f #<procedure prompting-meta-read (repl)>]
168: 5 [run-repl* # #<procedure prompting-meta-read (repl)>]
123: 4 [#<procedure 108da0520 at system/repl/repl.scm:118:4 (key . args)> system-error ...]
In ice-9/format.scm:
1593: 3 [format #<input-output: socket 16> "While reading _expression_:\n"]
766: 2 [format:format-work "While reading _expression_:\n" ()]
81: 1 [anychar-dispatch]
In unknown file:
?: 0 [write-char #\i #<input-output: socket 16>]
ERROR: In procedure write-char:
ERROR: In procedure fport_write: Broken pipe
Backtrace:
In ice-9/boot-9.scm:
157: 2 [catch #t #<catch-closure 109170c40> ...]
In unknown file:
?: 1 [apply-smob/1 #<catch-closure 109170c40>]
In ice-9/boot-9.scm:
157: 0 [catch #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