-
Notifications
You must be signed in to change notification settings - Fork 40
Description
Signals such as SIGSEV, SIGBUS, SIGABRT etc. are not handled by jupyter-xeus.
For instance the following reproducers crashes the kernel and lead to a restart.
int* x;
*x = 33;#include <cassert>
int x = 0;
assert(x > 0);While handling such cases is not easy (and not part of C++ error handling per say), I'd argue that current behaviour is unsatisfactory. The above example is trivial, but more complex algorithms can easily lead to to segfaults. For beginners this is absolutely incomprehensible.
A minimal solution may be to catch such signals and manage to display a message like:
The kernel has received a
SIGSEGVsignal, likely due to an error in the code, forcing a halt to the current execution.
The kernel should restart automatically, leaving you with a new execution context.
See also our documentation.
Pointing to a page on why jupyter-xeus cannot "catch" these error and why a restart is mandatory.
Also detailing good practices about notebook reproducibility.
Very nice to have would be to have a form of backtrack, with the code line number where this is happening. 🚀
I am not sufficiently knowledgeable about xeus-cpp to know how it should best be handled (perhaps executing in a sub-process?), especially in WASM. Perhaps this is even in scope for clang-repl?
Setup:
xeus-cpp==0.8.0on conda-forge- MacOS arm64 (M3)
- Regular xeus-cpp (non-lite)