and TCanvas

Hello ROOTers,
I tried to use TMapFiles and plot the content of them but ROOT crashes every time I try to draw a histogram. Here is a simple example using rootn.exe:

TMapFile *mf=TMapFile::Create("","recreate")                                   
(TMapFile *) 0x7fb052beb008                                                                     

TH1 *h=new TH1F("test","test",100,-5,5)                                                
(TH1 *) 0x556155030078                                                                          

Object               Class                Size                                                  
test                 (null)               0                                                     

h->Fill (0)                                                                            

Memory mapped file:                                                                  
Option:               CREATE                                                                    
Mapped Memory region: 0x7fb052be4000 - 0x7fb052c64000 (0.50 MB)                                 
Current breakval:     0x7fb052bef000                                                            


I also tried to generate the TMapFile in one thread and plot the histograms in another one but in this case I obtain the same error message. It seems that the TCanvas can not be created using rootn.exe

Finally I have build a standalone application to read the TMapFile content. This standalone application has been compile the following way:

g++ -o hInterpCons hInterpCons.C -Wl,–no-as-needed root-config --new --glibs --cflags --libs

I obtain again the same error message when trying to create a TCanvas.

Does anyone have a solution ?

Thank you for your help


ROOT Version: 6.24/06
Platform: Ubuntu 20.04.1
Compiler: gcc 9.4.0


@couet do you know why creating a canvas breaks when using rootn.exe?

@DanielCussol do you strictly need a TMapFile or you could also use a regular TFile?

I am not completely sure what rootn.exe is supposed to do. I think the “new” operator is somehow rewritten? right? with my build on Mac I cannot even start it:

% which root.exe
couet@imaccouet Downloads % rootn.exe     
zsh: segmentation fault  rootn.exe

Hello Olivier,
“rootn.exe” is maybe a legacy of old root versions. It is just the “root” executable linked with the library. The use of it is indicated when one try to create an instance of the TMapFile class in a standard ROOT session like this:

root [0] TMapFile *mf=TMapFile::Create("","recreate")
Error in <TMapFile::TMapFile>: no memory mapped file capability available
Use rootn.exe or link application against "-lNew"

If the TMapFile class is not maintained anymore in the new ROOT versions, I will forget to use it.



Hello Daniel,

I am not sure I am the best person to answer this question. I do not know about it. My be @pcanal knows more ?


Strictly speaking I do not need to use the TMapFile class. I have just seen in the (old) documentation that this could be a possibility to share TObjects for different threads or different ROOT simultaneous sessions. If the TMapFile class is obsolete, I will not use it in the future.




You can still share objects between threads without TMapFile (e.g. by running a lambda in a thread that captures a given histogram by reference). Of course if you write to them from multiple threads, you need to be aware whether they are thread-safe or not, and protect the accesses in the latter case (e.g. TH1 is not thread safe).

@pcanal can perhaps comment better on the use of rootn + TMapFile for simultaneous ROOT sessions.

It should not be used for sharing with threads. It is explicitly intended to use “shared memory” to pass information from one process to another.

So far on Ubuntu 20.04.4 and a debug build of the tip of the main branch, your example works for me.
However, it was failing before I upgraded in a Release build of an older version of ROOT (on Ubuntu 18). I will check if it works in a Release build with Ubuntu 20.04.4 and the tip of the main branch.

The problem appears “only” in some case of optimized build where vector assembly instruction are used by the compiler to execute object move operation.

The problem is solved by [libNewDelete] Over-align the allocation. by pcanal · Pull Request #11172 · root-project/root · GitHub.

You can also avoid the problem by rebuilding ROOT with the following additional cmake option: