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 #<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