Crash when moving or deleting TCanvas


I use a compiled library that I run from CINT on Windows and get this problem with both v5.26 and v5.27:

My code has methods that generate graphical output in two ways: either by instantiating new TH1F histograms, or by calling Draw from a TTree in a root file. The code also instantiates TCanvas windows and pads (using Divide) and draws the various plots.

If I use either one of the two types of methods, the one that instantiates histograms or the one that draws from TTree, then there is no problem and the windows can be moved around with the mouse or deleted.

If I combine the two types of methods and generate simultaneously windows using both, then I get crashes when I move the windows with the mouse, or delete them with the mouse or via the command line.

I have tried various combinations of SetBit(kCanDelete) or ResetBit(kCanDelete) for the objects I create, and also tried ResetBit(kMustCleanup) for the canvases and pads I generate, but the result is the same. The crash occurs in ROOT code and I haven’t been able to trace it.

I would appreciate any help.



Could you post the shortest possible system (script(s)) reproducing this problem?



I am attaching a script that sort of mimics my code:

void root_debug: the main
void MakeFile: creates a root file with a tree
void DrawHistograms: reads from the file, generates histograms for branches, draws them to new canvases
void DrawTree: draws branches 1-9 vs branch 0 to new canvases

It appears that DrawTree doesn’t crash ROOT, but DrawHistograms does:

In DrawHistograms: setting 0 <= i1 <= 8 and i2 = i1+1 the script draws a histogram for the i+1 th branch in a new canvas, but as soon as i2 - i1 > 1 (i.e. attempt to draw more than one branches at a time) then ROOT crashes.

This looks similar to the crash I reported.

root_debug.c (2.22 KB)

Hi Marios,

In this loop (in DrawHistograms()): int i1 = 0, i2 = 1; for (int i = i1; i < i2; ++i) { stringstream tmp; tmp << "branch_" << i; h[i-1] = GetHistogram(tree, tmp.str().c_str()); stringstream tmp2; tmp2 << "canvas_" << i; c[i-1] = new TCanvas(tmp2.str().c_str(),tmp2.str().c_str()); c[i-1]->cd(); h[i-1]->Draw(); h[i-1]->SetBit(kCanDelete); } When i = 0, you’re trying to access negative array elements ( at [i-1] )…

Cheers, Bertrand.

Hi Bertrand,

You are right, this was an oversight. Try the new fixed script. In my case it creates the first two canvases with histograms correctly, but then exits with errors:

returning histogram for branch_1
returning histogram for branch_2
Error: Symbol x is not defined in current scope
*** Interpreter error recovered ***
root [1]

There is no error if you only run for up to two histogram plots at a time in the DrawHistograms loop.

It is hard to reproduce the exact issue I reported without the full compiled library, which is erratic (i.e. the crash occurs without a definite pattern, like a memory leak or something). The error in the execution of this macro is different but may be related.

root_debug2.c (2.18 KB)

Hi Marios,

just to let you know that your problem has found a new home :slight_smile: I will debug it probably still tomorrow.

Cheers, Axel.

Hi Axel, Thanks!

I have created a Savannah bug report on it:

Cheers, Axel.


As a work-around the following should work:

int i1 = 0, i2 = 1; for (int i = i1; i < i2; ++i) { h[i-1] = GetHistogram(tree, TString::Format("branch_%d",i)); c[i-1] = new TCanvas(TString::Format("canvas_%d",i),TString::Format("canvas_%d",i)); c[i-1]->cd(); h[i-1]->Draw(); h[i-1]->SetBit(kCanDelete); }


Hi Philippe,

Your workaround doesn’t really work, it only changes the manifestation of the error.

In the second script I have posted, I tried replacing the stringstream variables in the calls to GetHistogram with the TString equivalents. The result was that the script generated four out of the nine graphs it should have (instead of two graphs with the original version), and then root crashed (instead of exiting the script with an error).

My code uses the stl library extensively, and I have often suspected spurious issues to be due to the mix of stl with CINT (or ROOT?). My hunch - for what it’s worth - is that CINT (or ROOT) and stl templates at times try to allocate the same memory.



[quote]My code uses the stl library extensively,[/quote]The best is likely to simply be compiling the code via ACLiC. (I am guessing that the dictionary for some of the stl container you are using is not (automatically or not) generated).