Structs, TFiles, and crashing ROOT

[mbanderson]

I have a short script here that can crash ROOT (5.22/00a) and I don’t know why.

The first part defines a struct, the main part of the program uses that struct.

[code]struct fileStruct {
TString name;
TFile *theFile;

fileStruct() {}

fileStruct(TString aName) {
this->name = aName;
this->theFile = new TFile(aName, “READ”);
if ( !this->theFile->IsZombie() )
cout << "Opened " << aName << endl;
else
cout << "Problem opening " << aName << endl;
}

Close() {
this->theFile->Close();
cout << "Closed " << this->name << endl;
}

} ;

void plotFromMultipleFiles() {
fileStruct theFiles[2];
theFiles[0] = fileStruct(“QCD_Pt15_Summer09.root”);
theFiles[1] = fileStruct(“QCD_Pt30_Summer09.root”);

theFiles[0].Close(); // This way will crash
//theFiles[0].theFile->Close(); // This way will not crash
}[/code]

If I run the above the command like so:
$ root -l
root[0] .x plotFromMultipleFiles.C
I get tons of garbage outputted to the screen.

What’s going on?

[mbanderson]

Another hint:
When using 5.25/02 on mac osx, and commenting out all close statements, I don’t get a horrible crash, but a weird error message:

> root -l plotFromMultipleFiles.C root [0] Processing plotFromMultipleFiles.C... Opened QCD_Pt15_Summer09.root Opened QCD_Pt30_Summer09.root root.exe(607) malloc: *** error for object 0x14776e4: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug root [1]

[Axel]

Hi,

it’s a problem with CINT. This works around the issue:

struct fileStruct {
  TString name;
  TFile *theFile;

  fileStruct(): theFile(0) {}

  void Init(TString aName) {
    this->name = aName;
    this->theFile = new TFile(aName, "READ");
    if ( !this->theFile->IsZombie() )
      cout << "Opened " << aName << endl;
    else
      cout << "Problem opening " << aName << endl;
  }

  void Close() {
    delete theFile;
    theFile = 0;
    cout << "Closed " << this->name << endl;
  }

} ;

void plotFromMultipleFiles() {
  fileStruct theFiles[2];
  theFiles[0].Init("QCD_Pt15_Summer09.root");
  theFiles[1].Init("QCD_Pt30_Summer09.root");

  theFiles[0].Close();             // This way will not crash anymore!
  //theFiles[0].theFile->Close();  // This way will not crash
}

The trick is to not copy the object.

Cheers, Axel.

[mbanderson]

Thanks for the help!

I decided, though, to abandon CINT and use python from now on.

I managed to create a very powerful and useful PyROOT script to plot from multiple files with different scales:

cmssw.cvs.cern.ch/cgi-bin/cmssw. … iew=markup

Python has been very good to me.

[Axel]

Hi,

I know that CINT’s parser is limited - it was designed to understand simple code, and nowadays that’s just not good enough anymore. So pyroot is indeed a way to work around it. The major disadvantage is that you cannot convert your code easily into the compiled world. So please promise me that you don’t write time critical analysis code in pyroot!

Cheers, Axel.

[brun]

and of course there is ACLIC that beats python by a factor 100 in performance.
As said by Axel, python is not the solution for data analysis.

Rene

[mbanderson]

I suppose I can only say that I’ve been amazed by how much code development time has decreased for me when using pyroot and python.

I’ve created several scripts in python/pyroot that took me an hour or two to write - whereas writing macros in C sometimes took me a whole workday or two.

[brun]

Axel or me do not claim that python is not a nice language.
It is not appropriate for data analysis. You can write a toy script to analyze a modest amount of data, but will be disappointed by the performance when doing real analysis. In this case you must use compile code and you are stuck with python at this point because you have to translate to C++ anyhow.
When writing analysis code, use ACLIC and you will see that the development + run time will be much better that what you can do with a simple python script.

By the way do not discuss python related problems in this thread. We have a dedicated thread on the Forum.

Rene

[mbanderson]

Thanks for the responses, this is interesting to hear.

By the way do not discuss python related problems in this thread.

I’m sorry about that, my posts were about a problem I was having with CINT.
I didn’t intend to discuss python, but I would like to respond to

[quote]Axel or me do not claim that python is not a nice language.
It is not appropriate for data analysis. You can write a toy script to analyze a modest amount of data, but will be disappointed by the performance when doing real analysis.[/quote]
The creator of Python said a few days ago:

I was blown away by the wide variety of Python use for scientific work. It looks like Python (with extensions like numpy) is becoming a standard tool for many sciences that need to process large amounts of data, from neuroimaging to astronomy.

Guido van Rossum said that on his blog after he met with a group at Berkley dedicated to developing Python-based tools for scientific research (Py4Science).
He mentioned some examples from that meeting including

The Hubble Space Telescope team in Baltimore has used Python for 10 years. They showed a tool for removing noise generated by cosmic rays from photos of galaxies. The future James Webb Space Telescope will also be using Python. (Perry Greenfield and Michael Droettboom, of STSCI.)

What I’ve been reading recently in Python Scripting for Computational Science has also shown python to be effective and appropriate in data analysis and other scientific aspects.

[Axel]

Hi,

none of this contradicts the fact that python is incredibly slow compared to compiled C++ code. It’s a dynamic interpreted language, there is no way out. And that’s all that Rene and I insist on pointing out Ask the guys at Google, who now try to accelerate youtube (mostly python) and who have a hard time, simply because the language won’t let them. I can understand that Guido can Rossum doesn’t go into detail here So use it like bash or perl: it’s easy to write but slow to run.

Cheers, Axel.