<TBufferFile::CheckCount>: Warning

Hi,

when writing a ROOT file, I got the following warnings (using ROOT 5.22/00 on linuxx8664 with gcc 4.3.2):

The writing is done by a ROOT-based software package which has worked fine for a long time, but now that I am dealing with a very large file (about 4 Gb) and a huge number of objects inside, these messages occur.

I have trouble to reproduce this problem with a test script though, it really seems to be related to the large file I am working with.

Looking at the code of TBufferFile, I see that these warnings or errors occur when the a certain value of kMaxMapCount is exceeded. What is the meaning of this? Could I just use a a larger value here? Or is there any other way out?

Any hint would be highly appreciated. Thanks!

Jens

Hi,

ROOT files currently do not support individual basket or buffer larger than 1Gb. You might be able to solve this problem by increasing the split level of your TTree.

Cheers,
Philippe.

Hi,

in my case, what is written to the file are only a few (but very large) objects, which, in turn, contain the actual data. I cannot change the structure of this, but I guess this might be the source of the problem. Is it correct that for each of these objects, a buffer is created which may not exceed 1 Gb?

Is this limit actually deep-rooted or is it rather arbitrary and could be changed? If there was such an easy change, this would probably be a way out for me, as I have no chance to modifiy the structure of our data myself.

Thanks in advance for any further information,

Jens

[quote]Is it correct that for each of these objects, a buffer is created which may not exceed 1 Gb?[/quote]That is correct.

[quote]Is this limit actually deep-rooted or is it rather arbitrary and could be changed? [/quote]It is deep rooted. The internal reference within the buffer are stored into 4 bytes entities and changing this represent a significant change in the file format.

[quote]as I have no chance to modifiy the structure of our data myself. [/quote]Humm … you may still be able to store large bits and pieces of the object and then get them back. If you send me the header file for your toplevel, I’ll try to give you some advises.

Cheers,
Philippe.

Hi Philippe,

I had a closer look into our code. The large object that causes the problem has several TLists as members, and the whole object is saved using the Write()-method inherited from TObject and with the option “kSingleKey”. I am not sure whether I understand this correctly: Could one avoid the problem by allowing more than one key here? And how would one then read back the object from the file? Is there an example for this somewhere?

Thank you very much in advance,

Jens

Hi,

The ‘kSingleKey’ would make a difference only if the object itself was a collection. In your case, I think the best would still to use a TTree (even with just one entry) as it would automatically split your object in small chunks. For example you could replace:// Writing myobject->Write(name,kSingleKey); .... // Reading myobject = (MyObject*)file->Get(name);with //Writing TTree *tree = new TTree(name,name); tree->Branch(name,&myobject); tree->Fill(); tree->Write(); .... // Reading TTree *tree; file->GetObject(name,tree); tree->SetBranchAddress(name,&myobject); tree->GetEntry(0);

Cheers,
Philippe.