Problem with netcat

Problem with netcat

[John Proctor]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

I posted this on IRC and it seems to not likely be a bug with guile but
maybe someone can help.  Other than this one issue, guile seems to run fine.
 I am using version 2.0.0 compiled from sources with:

$ export BDW_GC_CFLAGS=-L/usr/lib
$ export BDW_GC_LIBS=-lgc
$ ./configure --prefix=/custom/dir
$ make
$ make install

If I run:

$ guile --listen 9000

 the guile interpreter starts normal.  I can then go to another shell and
run

$ nc localhost 9000

 and access the running instance.  Everything seems to work normal.


However, if I take a scheme source file such as foo.ss with nothing more
than a single express e.g. (+ 1 1) and try :

$ nc localhost 9000 < foo.ss

the guile instance dies immediately with no errors or anything.


Any ideas on how I can debug what is going on would be appreciated.

Thanks,
John Proctor

[-- Attachment #2: Type: text/html, Size: 1349 bytes --]

Re: Problem with netcat

[Andy Wingo]

On Sun 03 Apr 2011 23:23, John Proctor <john.proctor@gmail.com> writes:

> However, if I take a scheme source file such as foo.ss with nothing more than a single express e.g. (+ 1 1) and try :
>
> $ nc localhost 9000 < foo.ss
>
> the guile instance dies immediately with no errors or anything.

Can anyone reproduce this error?

Andy
-- 
http://wingolog.org/

Re: Problem with netcat

[Detlev Zundel]

Hi,

> On Sun 03 Apr 2011 23:23, John Proctor <john.proctor@gmail.com> writes:
>
>> However, if I take a scheme source file such as foo.ss with nothing
>> more than a single express e.g. (+ 1 1) and try :
>>
>> $ nc localhost 9000 < foo.ss
>>
>> the guile instance dies immediately with no errors or anything.
>
> Can anyone reproduce this error?

I cannot reproduce the error, no.

John, what you might try is to start guile under control of "strace -f"
and see what happens when you connect with netcat.  This could give us a
hint on the reason for the termination.

Cheers
  Detlev

-- 
Computer scientists do it depth-first.

Re: Problem with netcat

[Detlev Zundel]

Hi John,

> Attached is the output of two strace runs.
> strace.netcat is of 'strace -r guile --listen=9000' with 'netcat localhost
> 9000 < a.ss' run against it.
> strace.interactive is of 'strace -r guile --listen=9000' with 'netcat
> localhost 9000' used to access it and me manually typing (+ 5 3) then
> hitting <ctrl>-d in both windows to terminate.
>
> Thanks Andy and Detlev.

Thanks for the input - I think the problem is clear to see here:

>      0.000033 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
>      0.000039 write(90, "scheme@(guile-user)> ", 21scheme@(guile-user)> ) = 21
>      0.000028 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>      0.000022 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
>      0.000032 read(0,  <unfinished ...>
>     30.150227 +++ killed by SIGPIPE +++

This is from the problematic log.  It turns out that an "strace -f"
would have be better advice for you so we would have seen the actual
socket process but funnily enough I now sometimes can regenerate the
error (usually by pressing C-c in netcat).

This is the last I see for such a case:

[pid   706] times({tms_utime=26, tms_stime=3, tms_cutime=0, tms_cstime=0}) = -1349846525
[pid   706] select(1024, [81], [], [], {0, 0}) = 0 (Timeout)
[pid   706] brk(0x9353000)              = 0x9353000
[pid   706] brk(0x934b000)              = 0x934b000
[pid   706] write(81, "scheme@(guile-user) [1]> ", 25) = 25
[pid   706] read(81, "", 1)             = 0
[pid   706] write(81, "\n", 1)          = 1
[pid   706] select(1024, [81], [], [], {0, 0}) = 1 (in [81], left {0, 0})
[pid   706] read(81, "", 1)             = 0
[pid   706] select(1024, [81], [], [], {0, 0}) = 1 (in [81], left {0, 0})
[pid   706] read(81, "", 1)             = 0
[pid   706] write(81, "\n", 1)          = -1 EPIPE (Broken pipe)
[pid   706] --- SIGPIPE (Broken pipe) @ 0 (0) ---
Process 706 detached
[pid 32521] +++ killed by SIGPIPE +++
[pid 32520] +++ killed by SIGPIPE +++
+++ killed by SIGPIPE +++

So it seems like guile wants simply to output a newline but the socket
is closed already and the process then gets the SIGPIPE signal which
guile is not prepared for.

I will need to dig deeper into the innards of guile to find an answer on
how to prevent that.  If someone beats me to it I'll still be happy ;)

Cheers
  Detlev

-- 
Number theorists do it perfectly and rationally.

Re: Problem with netcat

[Andy Wingo]

On Thu 07 Apr 2011 18:04, Detlev Zundel <dzu@denx.de> writes:

> So it seems like guile wants simply to output a newline but the socket
> is closed already and the process then gets the SIGPIPE signal which
> guile is not prepared for.

Excellent debugging, Detlev!  I pushed a (sigaction SIGPIPE SIG_IGN) to
(system repl repl), which should fix the issue.  Thanks for the
debugging, and thanks for the report, John!

Andy
-- 
http://wingolog.org/

Re: Problem with netcat

[Detlev Zundel]

Hi Andy,

> On Thu 07 Apr 2011 18:04, Detlev Zundel <dzu@denx.de> writes:
>
>> So it seems like guile wants simply to output a newline but the socket
>> is closed already and the process then gets the SIGPIPE signal which
>> guile is not prepared for.
>
> Excellent debugging, Detlev!  I pushed a (sigaction SIGPIPE SIG_IGN) to
> (system repl repl), which should fix the issue.  Thanks for the
> debugging, and thanks for the report, John!

Thanks for the fix - I can confirm that this works (guile survives) for
the cases where I saw the sigpipe before.

Cheers
  Detlev

-- 
I had nothing to do with implementing Gosmacs.  It was inspired
by the original Emacs, but that's all.  I would never have agreed
to use a language like Mocklisp.
             -- Richard Stallman in <E1CUySS-00048D-RN@fencepost.gnu.org>

Re: Problem with netcat

[John Proctor]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Thanks for the great response.

On Mon, Apr 11, 2011 at 10:32 AM, Detlev Zundel <dzu@denx.de> wrote:

> Hi Andy,
>
> > On Thu 07 Apr 2011 18:04, Detlev Zundel <dzu@denx.de> writes:
> >
> >> So it seems like guile wants simply to output a newline but the socket
> >> is closed already and the process then gets the SIGPIPE signal which
> >> guile is not prepared for.
> >
> > Excellent debugging, Detlev!  I pushed a (sigaction SIGPIPE SIG_IGN) to
> > (system repl repl), which should fix the issue.  Thanks for the
> > debugging, and thanks for the report, John!
>
> Thanks for the fix - I can confirm that this works (guile survives) for
> the cases where I saw the sigpipe before.
>
> Cheers
>  Detlev
>
> --
> I had nothing to do with implementing Gosmacs.  It was inspired
> by the original Emacs, but that's all.  I would never have agreed
> to use a language like Mocklisp.
>             -- Richard Stallman in <E1CUySS-00048D-RN@fencepost.gnu.org>
>

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

Re: Problem with netcat

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> wrote:
> I pushed a (sigaction SIGPIPE SIG_IGN) to (system repl repl), which
> should fix the issue.

Isn't this a bad idea?  SIGPIPE generally indicates that something went
wrong.  If we ignore it, important problems may go unnoticed.  To me,
this seems kind of like ignoring SIGSEGV to get around a memory access
to an unmapped area that would be inconvenient to prevent.

Furthermore, what happens if a REPL is started within a Guile process
that wants to install its own handler for SIGPIPE?

Why is a pipe being created here, anyway?  Why not just a socket?

     Best,
      Mark

Re: Problem with netcat

[Andy Wingo]

On Mon 11 Apr 2011 19:36, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> wrote:
>> I pushed a (sigaction SIGPIPE SIG_IGN) to (system repl repl), which
>> should fix the issue.
>
> Isn't this a bad idea?  SIGPIPE generally indicates that something went
> wrong.  If we ignore it, important problems may go unnoticed.  To me,
> this seems kind of like ignoring SIGSEGV to get around a memory access
> to an unmapped area that would be inconvenient to prevent.
>
> Furthermore, what happens if a REPL is started within a Guile process
> that wants to install its own handler for SIGPIPE?
>
> Why is a pipe being created here, anyway?  Why not just a socket?

Sorry, this isn't in (system repl repl), it's in (system repl server) --
so it's a socket.  If the socket is closed without cleanup, you might
get a SIGPIPE.  It's necessary in net-facing servers.  You don't get
this behavior if you don't --listen.

Regards,

Andy
-- 
http://wingolog.org/

Re: Problem with netcat

[Detlev Zundel]

Hi Mark,

> Andy Wingo <wingo@pobox.com> wrote:
>> I pushed a (sigaction SIGPIPE SIG_IGN) to (system repl repl), which
>> should fix the issue.
>
> Isn't this a bad idea?  SIGPIPE generally indicates that something went
> wrong.  If we ignore it, important problems may go unnoticed.  To me,
> this seems kind of like ignoring SIGSEGV to get around a memory access
> to an unmapped area that would be inconvenient to prevent.

We do not ignore the problem, we simply allow guile to recat to the
problem ;)

Where previously guile simply died, I now see this in the father
guile-process when the problematic situation arises:

,----[ Guile Output ]
| scheme@(guile-user)> Backtrace:
| In ice-9/boot-9.scm:
|  170: 17 [catch #t #<catch-closure a283a10> ...]
| In unknown file:
|    ?: 16 [catch-closure]
| In ice-9/boot-9.scm:
|  170: 15 [catch #t #<procedure a270a20 at system/repl/server.scm:115:10 ()> ...]
| In system/repl/server.scm:
|  122: 14 [serve-client #<input-output: socket 81> #(2 2130706433 49515)]
| In unknown file:
|    ?: 13 [with-continuation-barrier #<procedure a2837c0 at system/repl/server.scm:123:3 ()>]
| In ice-9/boot-9.scm:
|  170: 12 [catch #t #<catch-closure a2837b0> ...]
| In unknown file:
|    ?: 11 [catch-closure]
| In module/ice-9/r4rs.scm:
|  170: 10 [with-input-from-port #<variable a2ccf88 value: #<input: soft 967d8e8>> ...]
|  174: 9 [with-output-to-port #<variable a2cce30 value: #<output: file /dev/pts/1>> ...]
|  178: 8 [with-error-to-port #<variable a2cccd8 value: #<output: file /dev/pts/1>> ...]
| In system/repl/server.scm:
|  131: 7 [#<procedure 9a57f10 at system/repl/server.scm:129:15 ()>]
| In module/system/repl/repl.scm:
|  160: 6 [run-repl #]
|  123: 5 [#<procedure 9a4d280 at module/system/repl/repl.scm:118:4 (key . args)> read-error ...]
| In module/ice-9/format.scm:
| 1574: 4 [format #<input-output: socket 81> "While reading expression:
| "]
|  747: 3 [format:format-work "While reading expression:
| " ()]
|  234: 2 [anychar-dispatch]
|   80: 1 [format:out-char #\h]
| In unknown file:
|    ?: 0 [write-char #\h #<input-output: socket 81>]
| 
| ERROR: In procedure write-char:
| ERROR: In procedure fport_write: Broken pipe
| Backtrace:
| In ice-9/boot-9.scm:
|  170: 3 [catch #t #<catch-closure a283a10> ...]
| In unknown file:
|    ?: 2 [catch-closure]
| In ice-9/boot-9.scm:
|  170: 1 [catch #t #<procedure a270a20 at system/repl/server.scm:115:10 ()> ...]
| In system/repl/server.scm:
|  122: 0 [serve-client #<input-output: socket 81> #(2 2130706433 49515)]
| 
| system/repl/server.scm:121:2: In procedure serve-client:
| system/repl/server.scm:121:2: In procedure fport_write: Broken pipe
`----

Cheers
  Detlev

-- 
Don't trust everything you read, and don't assume every poster in
a thread is actually relevant to the problem.
        -- Stefan Monnier <jwvlj1gk44h.fsf-monnier+emacs@gnu.org>