Histogram created by TTree::Draw behaves erroneously

ROOT
1

Dear all,

I’m using the following piece of code to compute the number of entries in a tree, taking into account the fact that each entry has a weight which can be a user-defined TFormula. It’s somewhat more convenient than defining a TTreeFormula and looping over all entries manually.

[code]
TFile* myFile = new TFile(“filename.root”,“READ”);
TTree* myTree = (TTree*) myFile->Get(“Tree”);

myTree->Draw(“Entries$>>tempHist”, “some weight formula”, “goff”);
TH1F* tempHist = (TH1F*) gDirectory->Get(“tempHist”);
myEntries = tempHist->Integral();

delete tempHist;
tempHist = NULL;
delete myFile;
myFile = NULL;[/code]

The code (compiled with g++ and ROOT 6.02) runs without problems most of the time, but sometimes fails unpredictably: computing the Integral returns 0.

I have checked the following:

  • the TTree is sane, the weights are nonzero, and anyway:
  • I get the same error without using a weight
  • tempHist->GetEntries() returns the correct number (same as myTree->GetEntries())
  • looping over the bins of tempHist and summing the values given by GetBinContent() returns the correct value
  • writing tempHist to a file, then opening this file, getting the histogram, and computing its integral returns the correct (nonzero) value

Is this a bug or a feature? Of course there are ways around it, but I would like to know whether this behaviour can be expected for some reason I’m not aware of, or not…

Cheers,
Sébastien

2

Hi Sébastien,

this does not look normal at all.
Could you share the rootfile which would allow us to reproduce the problem?

Cheers,
Danilo

3

Hi Danilo,

I put the root file and the test script in /afs/cern.ch/user/s/swertz/public/temp_testbug

But when I try running it on lxplus, there is no problem.
Actually, there is no problem either when I execute the macro with ROOT 5.34.09. The problem appears when using 6.02.05, which is weird, because the root file causing the problem was created by a program compiled with this very same version.

4

Hi Sébastien,

thanks for sharing the material. I am not able to reproduce the issue. This is what I do (on lxplus):

echo Setup gcc
source /afs/cern.ch/sw/lcg/releases/gcc/4.8.1/x86_64-slc6/setup.sh 
echo setup ROOT
. /afs/cern.ch/sw/lcg/app/releases/ROOT/6.02.05/x86_64-slc6-gcc48-opt/root/bin/thisroot.sh
root -b -q bugtest.C

Even using the master (6.03), I continue to get stably this output:

Processing bugtest.C...
Integral = 0
nEntries = 974

Is there maybe some build remnant or misconfiguration in the environment settings of your shell?

Cheers,
Danilo

5

Hi Danilo,

Thanks for looking into it. I don’t understand why you say you cannot reproduce the bug, since the output you get is precisely the issue: the integral is zero, while it shouldn’t be (number of entries > 0, weights >0)!

Cheers,
Sébastien

6

Hi,

I meant I cannot reproduce the behaviour you describe:

The code (compiled with g++ and ROOT 6.02) runs without problems most of the time, but sometimes fails unpredictably: computing the Integral returns 0.

I never saw anything different from 0 all the time.

Cheers,
Danilo

7

Oh, I see! What I meant was that running the code on the file I shared, I always get the same (problematic) result, but that it runs (consistently) fine on other files.

The few lines are in a function part of a bigger project which reads many different files. The file I shared is one with which the problem appears (not the only one); if you want I can also share one for which everything runs fine?

Yours,
Sébastien

8

Hi,

I see what you mean now: you see 0 only with v6 and the correct number with v5. Looking into it.

Cheers,
Danilo

9

Hi Sébastien,

we are working on a fix which will be included in the next root versions. I’ll let you know when it is available in the repository.
Thanks a lot for reporting.

Cheers,
Danilo

10

Hi Danilo,

That’s great news, thanks! :slight_smile:

Do you think you could provide a patch to apply on the version installed on our server (6.02.05)?

Cheers,
Sébastien

11

Hi,

The fix is applied in both master and 6.02 patch branches.
If you cannot update the ROOT version, you can just call TH1::BufferEmpty() after having called the TTree::Draw method, as a simple workaround.

Cheers

Lorenzo

12

That helps!

Thank you again for your very efficient help,

Sébastien

13

Well, I’ve just updated to ROOT 6.04 and still experience this issue when using pyRoot (compiled C++ works fine)…
Could there be a link with [Wrong Event Count in ROOT 6.02.10 It’s also supposed to be fixed in 6.04, but I get the same problem with this version…