Dear RootTalk,
We (MINOS) have been having trouble filling TTrees since we moved to 5.08/00 on Scientific Linux SL Release 3.0.4 with gcc version 3.2.3
I have isolated the problem into a simple ACLiC macro in which there are two classes:-
class ClassA : public TObject {
Int_t event; Int_t num_2; Int_t num_3; Int_t num_4;
Int_t num_1; Int_t num_2; Int_t num_3; Int_t num_4;
that are used to fill a TTree and then display the contents:-
ClassB* class_b = new ClassB();
TTree* fNtuple = new TTree("NtupleTest", "Ntuple Test");
fNtuple->Branch("event.", "ClassB", &class_b, 64000, 2); fNtuple->Fill(); fNtuple->Show(0);
Although the object initialise themselves like this:-
ClassA() {
event = 1; num_2 = 2; num_3 = 3; num_4 = 4;
ClassB() {
num_1 = 101; num_2 = 102; num_3 = 103; num_4 = 104;
Tree::Show(0) produces:-
======> EVENT:0
event. = NULL event.ClassA.fUniqueID = 0 event.ClassA.fBits = 50331648 event.ClassA.event = 4 event.ClassA.num_2 = 101 event.ClassA.num_3 = 102 event.ClassA.num_4 = 103 event.num_1 = 101 event.num_2 = 102 event.num_3 = 103 event.num_4 = 104
The ClassA results have been shifted by 12 bytes and are actually returning part of ClassB. I have discovered that the problem is related to the fact that the TBranch name is "event." and ClassA has a member named "event". Changing the name of either is sufficient to fix the problem.
The attached ACLiC macro illustrates the problem. It runs fine under 4.04/02 but fails under 5.08/00 and 5.09/00 (taken from CVS head a few days ago).
Now, while it's perhaps not a good idea to duplicate an name like that I wasn't aware that it was a restriction. Is it now?
Thanks,
Nick West
This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:31:57 MET