-
Notifications
You must be signed in to change notification settings - Fork 0
[BUG] Weird Swank Crash, Possibly Unrelated #8
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
Comments
I don't think it's a ChanL bug anymore; probably reproducible in vanilla SLIME connected to multithreaded Swank without anything beyond the minimal testcase. |
I read very quickly, but my first guess is that:
I probably had a very similar issue when I wrote this code: https://github.com/fstamour/breeze/blob/268cd0eb872e54f2c7091f36fd10106e81719396/src/command.lisp#L230 |
Any idea which version of:
|
both loaded by
2.2.9.debian ( |
While recovering from indeterminate state of an image containing a long-running ScalpL cohort, one of Swank's threads stopped providing context information; the subsequent interruption from Emacs was not properly handled, leading to a disconnection from SLIME and ultimately contributing to loss of the image.
To Reproduce
Due to the indeterminate state reached by multiple killings and restartings of thread pool tasks, it is not obvious how to recreate the environment where an Emacs interruption caused this crash.
Expected behavior
Emacs interruptions should launch SLDB within a new buffer without losing connection to SLIME or killing any threads.
Error Log (taken from
*standard-output*
after SLIME disconnection)Relevant System Information:
x86_64SMPold-thread-pool
edit - emphasized relevant aspect of Hardware information
The text was updated successfully, but these errors were encountered: