Problem with TTree:Fill()

I have a tree with a large number of branches. If I call Fill enough times at some point the entries are filled with zeroes instead of the correct value.

I reduced the program to a few lines, with the exception of the branches declaration since the bug only appears when a large number of branches are used. You can find the example code in attachment.

Unfortunately the bug only appears on some machines (but on several versions of root). To try and help I am attaching the binary and a valgrind log. If there is anything else I can give you please let me know.

The program: demo.c fills a tree for a total of 30000 events. There are two variables, one is Nrunnumber and is always filled with 9999 and the other, Nevtda, is always filled with the iteration numbers, starting from 1.

Here is the output I get on one of the machine that show the bug:
[pcdreamdaq] ~ > cd DreamDaq/decode/demo
[pcdreamdaq] ~/DreamDaq/decode/demo > uname -a
Linux pcdreamdaq 2.6.18-194.8.1.el5 #1 SMP Fri Jul 2 10:10:27 CEST 2010 i686 i686 i386 GNU/Linux
[pcdreamdaq] ~/DreamDaq/decode/demo > make clean
[pcdreamdaq] ~/DreamDaq/decode/demo > make
g++ -O2 -g -Wall -I/usr/local/include -D_LINUX -D_VXWORKS -c demo.c root-config --cflags
g++ -o demo demo.o -lz -lpthread root-config --glibs -lThread
[pcdreamdaq] ~/DreamDaq/decode/demo > ./demo
output file: test.root
[pcdreamdaq] ~/DreamDaq/decode/demo > root test.root
root [0]
Attaching file test.root as _file0…
root [1] DREAM->Scan(“Nrunnumber:Nevtda:Entry$”,“Nevtda==0”);

  • Row * Nrunnumbe * Nevtda * Entry$ *

  • 5540 *         0 *         0 *      5540 *
  • 5541 *         0 *         0 *      5541 *
  • 5542 *         0 *         0 *      5542 *
  • 5543 *         0 *         0 *      5543 *


  • 5621 *         0 *         0 *      5621 *
  • 5622 *         0 *         0 *      5622 *
  • 5623 *         0 *         0 *      5623 *
  • 5624 *         0 *         0 *      5624 *

==> 85 selected entries
root [1]

As you can see there are 85 events with Nevtda=0, that should not be possible.

Can you help me with this?

Best wishes,

demo.tar.gz (152 KB)


The valgrind output does not show anything obviously wrong. One unusual thing is that the code:

ntbook(hasOSC, hasDRS); TFile *file = new TFile("test.root","RECREATE");create the TTree before opening the file and never explicitly attach it to the file. This means that the data, all the data, is kept in memory until the TTree is deleted. The example you send was bit in 32bits mode and thus this could be a problem is the total amount of data reach past 2Gb.

One plausible cause of the problem is that some of the array of ‘over-filled’ when the data is entered. For example there isint Nrunnumber; // Number of the Run unsigned int Nevtda = 0 ; // Number of data event .... unsigned int NSCA; // Total number of counts in Scaler unsigned int CHSCA[16]; // Channels in the scaler (the channel of the count) is for some reason CHSCA is used with an index greater than 15, then the value of NSCA, Nevtda might be inadvertently modified (and since all the data/array are contiguous, the problem can come from any of the arrays being overfilled/used out of bounds.