Strange behavior from passing a const char* to a func

ROOT
1

Hello,

I’ve written a program that analyzes data stored in a ROOT TTree. It’s too large to post, so I’ll describe it as best as I can. The master class in my program is called WZcuts, it provides the interface to the TTree and constructs a series of convience classes for each event (things like Electron, Muon, and MET). The main part of the program, WZanalysis, loops through the events in the TTree and fills histograms by fetching the objects from WZcuts. No problems with this.

The odd behavior started when I added a class to run systematics, WZSystematics. All it really does is, based on options passed to it, order WZcuts to rebuild the objects after shifting some of the values.
I first added it to WZanalysis as a test like this:

int main_loop(TChain* oldtree, char* ftag, bool MuStream) {
    WZcuts evt;
    evt.SetChain(oldtree);
    WZSystematics syst;
    syst.SetWZcuts(evt);//pass by reference
    for (Long64_t entr_ind = 0; entr_ind < tree_Entries; entr_ind++) {
        oldtree->GetEntry(entr_ind);
        evt.makeObjects(); 
        /*fill lots of histograms.....(code break)
         * ......*/
        syst.RunSystematics("eIsoPt eIsoNPV eSmear",weight);
    }
}

This caused my MET value to be NAN, even if I check it before RunSystematics is called! Just commenting the line with RunSystematics restored the MET value to normal.

Here’s the RunSystematics method:

void WZSystematics::RunSystematics(string options,double weight){
    if(!m_evt || !m_hb){
        cerr<<"ERROR: WZcuts object and HistoBuilder objects are not set!\n";
        return;
    }
    m_weight=weight;
    //save current electron configuration------
    int IsoNPV_Syst=Electron::IsoNPV_Syst;
    int IsoPt_Syst=Electron::IsoPt_Syst;
    int Smear_Syst=Electron::Smear_Syst;
    //-----------------------------------------
        
    //Run Baseline values--------------------------
    string syst="base_";
    setBaseSystOpts();
    m_evt->makeObjects();
    runCutflow(syst);
    //-----------------------------------------
    //electron isolation NPV correction systematic
    if(options.find("eIsoNPV")!=string::npos){
        syst="eIsoNPV_dwn";
        setBaseSystOpts();
        Electron::IsoNPV_Syst=1;
        m_evt->makeObjects();
        runCutflow(syst);
        
        syst="eIsoNPV_up";
        setBaseSystOpts();
        Electron::IsoNPV_Syst=2;
        m_evt->makeObjects();
        runCutflow(syst);
    }
    //electron isolation pT correction systematic
    if(options.find("eIsoPt")!=string::npos){
        syst="eIsoPt_dwn";
        setBaseSystOpts();
        Electron::IsoPt_Syst=1;
        m_evt->makeObjects();
        runCutflow(syst);
        
        syst="eIsoPt_up";
        setBaseSystOpts();
        Electron::IsoPt_Syst=2;
        m_evt->makeObjects();
        runCutflow(syst);
    }
    //electron smearing correction systematic
    if(options.find("eSmear")!=string::npos){
        syst="eSmear_dwn";
        setBaseSystOpts();
        Electron::Smear_Syst=1;
        m_evt->makeObjects();
        runCutflow(syst);
        
        syst="eSmear_up";
        setBaseSystOpts();
        Electron::Smear_Syst=2;
        m_evt->makeObjects();
        runCutflow(syst);
    }
    //return original electron configuration------
    Electron::IsoNPV_Syst=IsoNPV_Syst;
    Electron::IsoPt_Syst=IsoPt_Syst;
    Electron::Smear_Syst=Smear_Syst;
    //--------------------------------------------
    
}

After lots of debugging I found that calling RunSystematics like this:

        string opts="eIsoPteIsoNPVeSmear";
        syst.RunSystematics(opts,weight);

fixed my problem. I have no idea why that makes a difference, especially since RunSystematics never touches the MET object itself and doesn’t pass the string options to any other methods. Is this a common problem passing a const char* as a string parameter? Was the const char* getting lost somehow and interfering with my branch assignment?

Thanks for your time,
Stephen

2

HI Stephen,

Did you run your example as code interpreted by CINT or as compiled code?

Philippe.

3

I compile it into an executable.

4

Hi,

Then if I understood correctly your description there is no good reason from the problem to go away and I would guess that the problem is still ‘there’ but is presenting itself differently (and the problem is some sort of memory overwrite). I recommend that you run your example in valgrind to pinpoint the issue ; if valgrind does not point to any obvious issue, please send us a complete running example reproducing the problem.

Cheers,
Philippe.