when executing the following code in Jupyter, an exception is silently caught by the ROOT kernel and the code ends with a segmentation fault. When running the same code from the ROOT application, the message of the caught exception is displayed, as you can see in the transcript of the code execution below.
root [0] ROOT::RDataFrame rd(10);
root [1] h = *rd.Histo1D(“foo”);
Error in TRint::HandleTermInput(): std::runtime_error caught: Unknown column: foo
root [2] h.Draw()
*** Break *** segmentation violation
[stack backtrace…]
Without the exception message it’s difficult to identify the problem is less trivial similar cases, where the user made a typo in the column name.
I’ve attached the screenshot of the code execution in Jupyter,
Is there an option to enable the display of the exception error or to disable the catching ?
Let me know if I should open a JIRA bug report: I see two problems: the message that is not displayed and the undefined state of the variable h, that leads to a segmentation violation later in the code.
I’ve tested the code snippet with ROOT built on Debian from the git tag v6-19-02 for both root application and Jupyter and also for Jupyter with the ROOT release currently used by SWAN (6.18/00). I will test it with 6.20.00 as soon I have installed it.
Yes, this is a problem of the Jupyter kernel for ROOT C++. It looks like the Python side of the kernel fails to capture the error from the C++ side (there is an I/O handler for this). Please feel free to open a ticket.
Regarding the RDataFrame part, there should be an error saying that foo is not a column of your dataset. I understand this is not the case? Then I would open another ticket for this one too.
root [0] ROOT::RDataFrame df(10);
root [1] auto h = df.Histo1D("foo");
Error in <TRint::HandleTermInput()>: std::runtime_error caught: Unknown column: foo
This seems to be an issue in the ROOT interpreter where a shared_ptr temporary causes a segfault:
// this is on lxplus sourcing /cvmfs/sft.cern.ch/lcg/views/LCG_96python3/x86_64-centos7-gcc8-opt/setup.sh
root [2] df.Histo1D("foo");
*** Break *** segmentation violation
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0 0x00007f3f0962141c in waitpid () from /lib64/libc.so.6
#1 0x00007f3f0959ef12 in do_system () from /lib64/libc.so.6
#2 0x00007f3f0a725d03 in TUnixSystem::StackTrace() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.18.00-885ca/x86_64-centos7-gcc8-opt/lib/libCore.so
#3 0x00007f3f0a7285d4 in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.18.00-885ca/x86_64-centos7-gcc8-opt/lib/libCore.so
#4 <signal handler called>
#5 0x00007f3f04d30577 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.18.00-885ca/x86_64-centos7-gcc8-opt/lib/libCling.so
#6 0x00007f3f0aec64ed in ?? ()
#7 0x00000000026bd130 in ?? ()
#8 0x00000000026bd130 in ?? ()
#9 0x00007ffd8c1429c0 in ?? ()
#10 0x00007f3f0aec64ac in ?? ()
#11 0x00000000018a3910 in ?? ()
#12 0x00000000026bd130 in ?? ()
#13 0x00007ffd8c1429e0 in ?? ()
#14 0x00007f3f0aec1620 in ?? ()
#15 0x0000000000000000 in ?? ()
===========================================================
Indeed the error message is displayed when running from the ROOT application, it's only on Jupyter that it is not. Nevertheless, in both case we have a segmentation fault in the next statement.
