TTree says "no dictionary" for class, but ".c

I have an odd problem. I define 2 simple classes in a file (basically 'struct’s with ctors/dtors). One class (mvdTreeEvent) contains a TClonesArray* of the other (mvdTreeADC). Both classes have public inheritance from TObject. I make a CINT dictionary and link it. When I try to make a tree of mvdTreeEvent like this:

mvdTree = new TTree(“mvdTree”, “MVD ADCs”);
mvdTree->Branch(“mvdEvent”, “mvdTreeEvent”, &mvdEvent, 64000, 0);

(the mvdTreeEvent ctor has
pADCs = new TClonesArray(“mvdTreeADC”, 6048);
)

I get the following errors:

Warning in TClass::TClass: no dictionary for class mvdTreeADC is available
Error in TClonesArray::TClonesArray: mvdTreeADC does not inherit from TObject

However, when I do “.class mvdTreeADC”, I get:

===========================================================================
class mvdTreeADC
size=0x2c
(tagnum=3004,voffset=-1,isabstract=0,parent=-1,gcomp=0:-1,d21=~cd=75)
List of base class--------------------------------------------------------
0x0 public: TObject //Basic ROOT object
List of member variable---------------------------------------------------
Defined in mvdTreeADC
(compiled) 0xc Int_t iPacket
(compiled) 0x10 Int_t iPad
(compiled) 0x14 Int_t iChip
(compiled) 0x18 Float_t fR
(compiled) 0x1c Float_t fPhi
(compiled) 0x20 Float_t fZ
(compiled) 0x24 Int_t bZeroSup
(compiled) 0x28 Int_t iADC
(compiled) 0x0 private: static TClass* fgIsA
List of member function---------------------------------------------------
filename line:size busy function type and name (in mvdTreeADC)
(compiled) 0:0 0 public: mvdTreeADC mvdTreeADC(void);
(compiled) 0:0 0 public: static TClass* Class(void);
(compiled) 0:0 0 public: static const char* Class_Name(void);
(compiled) 0:0 0 public: static Version_t Class_Version(void);
(compiled) 0:0 0 public: static void Dictionary(void);
(compiled) 0:0 0 public: virtual TClass* IsA(void) const;
(compiled) 0:0 0 public: virtual void ShowMembers(TMemberInspector& insp,char* parent);
(compiled) 0:0 0 public: virtual void Streamer(TBuffer& b);
(compiled) 0:0 0 public: void StreamerNVirtual(TBuffer& b);
(compiled) 0:0 0 public: static const char* DeclFileName(void);
(compiled) 0:0 0 public: static int ImplFileLine(void);
(compiled) 0:0 0 public: static const char* ImplFileName(void);
(compiled) 0:0 0 public: static int DeclFileLine(void);
(compiled) 0:0 0 public: mvdTreeADC mvdTreeADC(const mvdTreeADC&);
(compiled) 0:0 0 public: virtual void ~mvdTreeADC(void);

It seems the dictionary is available to CINT, but TClonesArray can’t find it! Any suggestions would be very much appreciated.

I’m using ROOT 3.05/07 on Linux 2.4.22 w/ glibc 2.3.2, gcc 3.2

Hi,

This is strange. I assume you generated the dictionary using ‘rootcint’.
Try executing:

Philippe

Hi Philippe,
I have no problem getting the class object:

root [15] mvdTreeADC *n = new mvdTreeADC
root [16] n->InheritsFrom(“mvdTreeADC”)
(const Bool_t)1
root [17] n->InheritsFrom(“TObject”)
(const Bool_t)0
root [18] gROOT->GetClass(“mvdTreeADC”)->ls()
OBJ: TClass mvdTreeADC : 0 at: 0x9e978c0
root [19] mvdTreeADC::Class()->ls()
OBJ: TClass mvdTreeADC : 0 at: 0x9e978c0
root [20] TClonesArray *array = new TClonesArray(“mvdTreeADC”)
Error in TClonesArray::TClonesArray: mvdTreeADC does not inherit from TObject
root [21]

Despite the fact that I can call the TObject methods “GetClass” and “InheritsFrom”, ROOT doesn’t know that mvdTreeADC inherits from TObject. Very confusing.

Yes, I generate the dictionary using rootcint. Interestingly, if I just compile and load the class definition file by:

.L mvdTree.C++
TClonesArray *array = new TClonesArray(“mvdTreeADC”)

I get no complaints. Somewhere in the infrastructure of the PHENIX online code, access to the dictionary is (partially) lost. I’d like to post a compact example to demonstrate the problem, but I am having difficulty reproducing it outside of the PHENIX software.

Thanks,
Ben

Hi,

It seems that you have a fundamental (likely environment related and/or memory corruption related).

The result of:

should have been 1 (and it is 0).

I would need a way to reproduce this problem to investigate it further.

Cheers,
Philippe.