segmentation faults in kernel

[lisp]

when run either in a console or from a notebook, the kernel responds to at most one execution message:

james@de10:/development/source/library/com/github/lisp/cl-jupyter$ jupyter console --kernel=lisp
; loading #P"/development/source/library/com/github/lisp/cl-jupyter/cl-jupyter.lisp"

cl-jupyter: an enhanced interactive Common Lisp REPL
(Version 0.7 - Jupyter protocol v.5.0)
--> (C) 2014-2015 Frederic Peschanski (cf. LICENSE)

kernel configuration = ((shell_port . 45106) (iopub_port . 40205)
                        (stdin_port . 35629) (control_port . 44938)
                        (hb_port . 48466) (ip . 127.0.0.1)
                        (key . eb269086-a78f4477c18a51673407b7d0)
                        (transport . tcp) (signature_scheme . hmac-sha256)
                        (kernel_name . lisp))
[Hearbeat] starting...
[Kernel] Entering mainloop ...
[Shell] loop started
[Heartbeat] thread started
WARNING:
   [Shell] message type 'history_request' not (yet ?) supported, skipping...
Jupyter console 5.2.0

cl-jupyter


In [1]: 1WARNING:
   [Shell] message type 'is_complete_request' not (yet ?) supported, skipping...
/home/james/anaconda3/lib/python3.7/site-packages/jupyter_console/ptshell.py:617: UserWarning: The kernel did not respond to an is_complete_request. Setting `use_kernel_is_complete` to False.
  warn('The kernel did not respond to an is_complete_request. '
In [1]: 1
Out[1]: 1

In [2]: 1
      : 

when the send/receive functions are traced, it appears that the last operation is a call to receive the next message, which never returns.
when run from a notebook, the notebook believes its next execution request times out and that the kernel has died.

when the kernel process is traced, this appears in the strace transcript:

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x10006757b0} ---
mprotect(0x1000670000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
rt_sigreturn({mask=[]})                 = 68721402799
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x10035bc110} ---
mprotect(0x10035b8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
rt_sigreturn({mask=[]})                 = 537919511

is this a known failure mode?

[fredokun]

This jupyter console behavior is strange (and I can reproduce it) ... and the tracing is cumbersome in the console... I think it has to do with a known low-level message encoding issue with cl-jupyter... This is being worked on (slowly ...).

[fredokun]

The byte-fix makes things a little bit smoother but there is this annoying "return" bug in the console. However, the jupyter console support is not a priority for now. I'll still keep the issue open.