ROOT 6.28 and Jupyter not Draw-ing [SOLVED]

[seligman]

Before I get into details, I’ll ask the basic question that might lead me to the answer: What is the component within ROOT and Jupyter that causes images to be displayed on a notebook page?

The issue in more detail:

I have a working JupyterHub installation running C++ and Python kernels with ROOT 6.26 under AlmaLinux 9.1. The purpose of the installation to make these kernels available for the students at our lab.

In order to provide my users with the latest and greatest, I tried updating the software framework with:

dnf -y update root\*

The results made me glad that I put the installation on a virtual machine so I could fall back to an earlier instance. When ROOT was updated to 6.28, it introduced a flaw in Jupyter: When I try to Draw something that puts actual graphics on the web page, the ROOT kernel (whether C++ or Python) dies. What’s more, it does so without leaving any form of error message in /var/log/messages or anywhere else that I’ve been able to locate.

For example:

TH1D hist("example","example",100,-3,3);
hist.FillRandom("gaus",10000);
hist.Draw();
c1->Draw();

In my 6.28.02 Jupyter installation, the kernel will die on the fourth line.

• This issue does not occur in my ROOT 6.26 installation. That works fine.

• This is not a problem with ROOT itself. If I run ROOT via the command line, or run ipython and type similar commands, the plot is displayed. It’s only an issue if I try to Draw from within Jupyter.

• The issue is located in my JupyterHub installation somewhere. I confirmed this by creating a Docker container with AlmaLinux 9 and ROOT 6.28/02 (wgseligman/jupyter-pyroot:latest-amd64, or wgseligman/jupyter-pyroot:latest-arm64 if you’re using an M1/M2 Mac). The issue does not occur within that container.

• I’ve done more than just dnf -y install root\* as I attempted to assess the issue. I updated everything in the system with dnf -y update; I updated all the pip packages including:

   pip3 install --upgrade jupyter jupyterlab jupyterhub "jupyter-server<2.0.0"
  

  The issue persists.

• My jupyterhub installation is complex, since it includes more than just the C++ and Python ROOT kernels. I’d father not have to rebuild it from scratch.

My conclusion is that there’s some piece of the Jupyter installation that I did not upgrade properly. However, without any error messages, I can’t determine what it is.

This leads back to my initial question: What part of ROOT+Jupyter actually puts images into the Jupyter notebook page? If I at least knew that, perhaps I could track down what’s going wrong.

---

Please read tips for efficient and successful posting and posting code

ROOT Version: 6.28.02
Platform: AlmaLinux 9
Compiler: gcc 11.3.1

---

[vpadulan]

Dear @seligman ,

That’s an interesting problem, indeed I tried with ROOT 6.28, 6.28/02 and master on my machine and the jupyter notebook does properly show the graphics. The graphics should be shown via traditional ROOT graphics (TCanvas & friends), unless you are using JsROOT (with the %jsroot on magic in the notebook cell), which injects some javascript to make the graphics interactive, which needs TBufferJSON to work properly (so the -Dhttp=ON flag when building, but you are installing via dnf so that should not be an issue). If you haven’t done it already, you could try outputting the debug information from the notebook via something like jupyter notebook --debug > log.file 2>&1.

Cheers,
Vincenzo

[seligman]

I solved the problem. Of course, the issue was where I least expected it.

I kept running tests, and discovered that sometimes I could execute Draw, and other times Draw would hang. I finally found a correlation: The .ipynb would draw correctly except when it was located in one specific directory. That directory was the one in which I kept my ROOT tutorial files.

I concluded that there was a “poisoned file” in that directory that caused the failure. After a “binary search”, I found the culprit: It was a .so file that I created years ago and paid no attention to. Evidently this old file, compiled using whatever ROOT version was current in 2015, is no longer compatible with ROOT 6.28. Go figure!

I deleted the .so file, and I could draw things again. I regenerated the .so file using the script I first created in 2015, and I could still draw things.

An idle question: Why would the presence of this old file cause a problem with ROOT? I could understand a problem if I were loading the library by default in rootlogon.C, but I was not. There must be some aspect of ROOT 6.28 that was not in ROOT 6.26 where it’s scanning its current directory looking for .so files. Does anyone know what that could be?