Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SBCL Lisp kernel keeps restarting (Looping) #29

Open
athena007 opened this issue Feb 21, 2017 · 6 comments
Open

SBCL Lisp kernel keeps restarting (Looping) #29

athena007 opened this issue Feb 21, 2017 · 6 comments

Comments

@athena007
Copy link

Hello

I am running sbcl 1.3.14 together with slime and everything works fine in emacs. I also run jupyter 4.1.0 with a few kernels. which are working fine.

I am hoping to utilized the jupyter notebooks interface for my class but i am getting a kernel loop or restart anytime i launch the SBCL lisp. Below is the error. Assistance will be very much appreciated to resolve this issue.

`[I 11:55:57.920 NotebookApp] KernelRestarter: restarting kernel (4/5)
WARNING:root:kernel d4136aa7-e963-4491-9023-914d7f1d690f restarted
This is SBCL 1.3.14, an implementation of ANSI Common Lisp.
More information about SBCL is available at http://www.sbcl.org/.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
To load "cl-jupyter":
Load 1 ASDF system:
cl-jupyter
; Loading "cl-jupyter"
^C[I 11:55:58.681 NotebookApp] interrupted
Serving notebooks from local directory: /home/kofi/notebooks
1 active kernels
The Jupyter Notebook is running at: http://localhost:8888/
Shutdown this notebook server (y/[n])? ......

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 = ((control_port . 37949) (shell_port . 45585)
(stdin_port . 57295) (signature_scheme . hmac-sha256)
(hb_port . 52669)
(key . 12b86afd-e852-471e-9d64-4b8ecb69833c)
(transport . tcp) (kernel_name . lisp)
(iopub_port . 59293) (ip . 127.0.0.1))
[Hearbeat] starting...
[Heartbeat] thread started
[Kernel] Entering mainloop ...
[Shell] loop started
Argh! corrupted error depth, halting
fatal error encountered in SBCL pid 795(tid 140737353875072):
%PRIMITIVE HALT called; the party is over.
`

Thanks

@athena007
Copy link
Author

I just resolved this issue. Indeed it was an issue related to 32bit / 64 bit conflict of pzmq.
I needed to update my quicklisp dist pkg.
If your are running sbcl then launch from terminal and run the following

  1. (load "~/quicklisp/setup.lisp")
  2. (ql:update-all-dists)

This is indeed related to issues with pzmq as discussed in the following link
http://stackoverflow.com/questions/34093656/jupyter-and-common-lisp
Updating the pkgs resolves the incompatibility.

I now have the following warning:

[Recv]: issue with UTF-8 decoding
WARNING: [Shell] message type 'comm_open' not (yet ?) supported, skipping...

Any clues as to their impact and resolution will be very much appreciated.

cheers

@fredokun
Copy link
Owner

The zmq dependency of jupyter is a little bit painful, but thanks to the reactivity
of the pzmq guys things end up by working, apparently...

The "issue with UTF-8 decoding" things is still quite obscure for me, but does not seem to be a big problem. I have used cl-jupyter for long sessions without much difficulty, and the .ipynb file is generally quite hard to corrupt.

For the moment cl-jupyter does not support the comm messages because I have yet to understand their purpose... I will look into that ASAP.

@ivanberry
Copy link

on macOs, This issue still happens, even after following @athena007 advice. with ccl, the jupyter notebook still keep restart after create a new notebook.

os: 10.13.3
CCL: Version 1.11-r16635 (DarwinX8632)
Python: Python 3.6.1

by following the quicklisp installation, and then update all dist.

@fredokun
Copy link
Owner

please check the new version in master, I think this particularly annoying bug is fixed (or at least addressed)

@fredokun
Copy link
Owner

I have yet to try with ccl on a mac computer, which I do not own...

@peter-ch
Copy link

peter-ch commented Dec 3, 2018

I'm not sure if this is the same problem but I get this (and the kernel keeps trying to restart but never starts):

To load "cl-jupyter":
Load 1 ASDF system:
cl-jupyter
; Loading "cl-jupyter"
.................

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

kernel configuration = ((ip . 127.0.0.1) (signature_scheme . hmac-sha256)
(hb_port . 55469) (transport . tcp)
(control_port . 41857) (shell_port . 37717)
(stdin_port . 60013) (iopub_port . 36781)
(key . d0bec1a5-86de2d74d0654908728b1c55)
(kernel_name . lisp))
[Hearbeat] starting...
[Kernel] Entering mainloop ...
[Shell] loop started
CORRUPTION WARNING[Heartbeat] thread started
in SBCL pid 588(tid 140737353897728):
Memory fault at (nil) (pc=0x1000a5d897, sp=0x7ffff2880358)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
CORRUPTION WARNING in SBCL pid 588(tid 140737353897728):
Memory fault at 0x7974697467 (pc=0x10014b05a2, sp=0x7ffff28800d8)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
INFO: Control stack guard page unprotected
CORRUPTION WARNING in SBCL pid 588(tid 140737353897728):
Memory fault at (nil) (pc=0x1000a5d897, sp=0x7ffff2878018)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
fatal error encountered in SBCL pid 588(tid 140737353897728):
Control stack exhausted, fault: 0x7ffff2877f88, PC: 0x415f9b

[I 12:39:56.232 NotebookApp] KernelRestarter: restarting kernel (1/5), keep random ports
This is SBCL 1.3.1.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at http://www.sbcl.org/.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants