Home | News | Documentation | Download

Odd memory leak

Hi All,

Currently working on a macro in which I access entries in a ROOT tree and use the branches for some calculations. Here is the script:

#include <iostream>
#include <fstream>
#include "TMath.h"
#include "TString.h"

using namespace std;

void test_script() {

// This stuff is necessary, but don't know why???

   TString name, name2, name3, title;

   TCanvas *c1 = new TCanvas("c1","c1",10,10,800,600);

// End of confusingly necessary items

   int nph, ev;
   float y, z;
   float y_adj, z_adj;

   TFile* datafile = new TFile("rand_flood.root");
   TTree* datatree = (TTree*)(datafile->Get("dstree"));

   int nentries = datatree->GetEntries();

   cout << nentries << endl;

   datatree->SetBranchAddress("nph", &nph);
   datatree->SetBranchAddress("ev", &nph);
   datatree->SetBranchAddress("y", &y);
   datatree->SetBranchAddress("z", &z);

   float ph_y[nph], ph_z[nph], ph_wl[nph];
   int ph_pid[nph];
   float y_bar, z_bar, y_w, z_w, c_w;

	float y_pmt[19] = {0, 0, 0, 0, 0, 30.31, 30.31, 30.31, 30.31, 60.62, 60.62, 60.62, -30.31, -30.31,
      -30.31, -30.31, -60.62, -60.62, -60.62};

   float z_pmt[19] = {0, 35, 70, -35, -70, -52.5, -17.5, 17.5, 52.5, -35, 0, 35, -52.5, -17.5, 17.5, 
      52.5, -35, 0, 35};

   int k;

   float weight[19];

   datatree->SetBranchAddress("ph_y", ph_y);
   datatree->SetBranchAddress("ph_z", ph_z);
   datatree->SetBranchAddress("ph_pid", ph_pid);

   TH2F *h1 = new TH2F("h1", "Position reconstruction for randomly distributed events", 200, -100, 100, 200, -100, 100);

   for(int i = 0; i <= nentries; i++)
      	y_bar = 0;
      	z_bar = 0;
      	y_w = 0;
      	z_w = 0;
      	c_w = 0;

      	y_adj = y*10;
      	z_adj = z*10;

      	for(int j = 0; j <= nph; j++)
        	if(ph_pid[j] <= 28 && ph_pid[j] >= 10)
            	k = ph_pid[j] - 10;


      	for(int l = 0; l <= 18; l++)
         	weight[l] = pow(weight[l],3);
         	c_w += weight[l];
         	y_w += y_pmt[l]*weight[l];
         	z_w += z_pmt[l]*weight[l];


      	y_bar = y_w/c_w;
      	z_bar = z_w/c_w;



	cout << "Hello" << endl;


Notice in the above script I have noted that the variables name, name2, name3, title and the initialization of a canvas are necessary to in order for the script to run as intended. When both are commented out, the value of nentries is printed to the terminal and I receive the error:

 *** Break *** segmentation violation
[/usr/local/Cellar/root/6.22.06_2/lib/root/libCore.so] TUnixSystem::DispatchSignals(ESignals) (no debug info)
[/usr/local/Cellar/root/6.22.06_2/lib/root/libCore.so] SigHandler(ESignals) (no debug info)
[/usr/local/Cellar/root/6.22.06_2/lib/root/libCore.so] sighandler(int) (no debug info)
[/usr/local/Cellar/root/6.22.06_2/lib/root/libCore.so] textinput::TerminalConfigUnix::HandleSignal(int) (no debug info)
[/usr/local/Cellar/root/6.22.06_2/lib/root/libCore.so] (anonymous namespace)::TerminalConfigUnix__handleSignal(int) (no debug info)
[/usr/lib/system/libsystem_platform.dylib] _sigtramp (no debug info)
[/usr/local/Cellar/root/6.22.06_2/lib/root/libCore.so] TObjArray::AddAt(TObject*, int) (no debug info)

With just the variables commented out, the script appears to open a canvas and the value of nentries is printed to the terminal, but then ROOT quits.

With just the canvas commented out, the value of nentries is printed to the terminal and I receive the same error listed above, which I find odd since in previous scripts I have not needed to initialize a canvas in order to generate a figure.

Any and all help is greatly appreciated.

ROOT Version: 6.22/06
Platform: MacOSX64
Compiler: gcc

To run your macro we need rand_flood.root

the most obvious issue is int nph, ev; (nph is not initialized) followed by float ph_y[nph], ph_z[nph], ph_wl[nph]; (these arrays now have undefined size).

nph should be initialized to the maximum size those arrays can have.

You might want to take a look at RDataFrame for a higher-level, friendlier interface to process TTrees and e.g. produce histograms out of them.


Hi @eguiraud,

Ah yes, a common mistake. And now it works. Thank you also for pointing me in direction of the RDataFrame resource. Thank you so much!