Cannot have more than 255 TProcessID's in one file ?

Hi,

I am using ROOT to write out TTrees containing objects refering to each others using TRef's. This works well, but I run into problems when trying to merge a large number of such trees produced by different jobs.

Starting out with 300 files, each containing a TTree and a TProcessID object, I load the files into a chain and then try to merge everything into a single file by copying the events one by one into a new file. When the number of initial files is N<255, this works and a file is produced that contains a TTree and N TProcessID objects. For N>=255, the produced file still looks OK (it contains a tree and a long list of TProcessIDs) but it is corrupted: all TRefs that are associated with ProcessID255 and above cannot find the object they point to even after it is loaded. Also, in this latter case, the file actually contains N+1 TProcessIDs : ProcessID1-ProcessID254 are correct, ProcessID255 is actually the process ID of the ROOT session during which the files were merged and ProcessID256-ProcessID(N+1) are the remaining ones.

>From looking into the TRef/TProcessID code it seems this is due to a
limitation of ROOT: apparently the index of the TProcessID is encoded into the upper 8 bits of the TObject's unique ID, at least that's how it seems to be used in TProcessID::GetProcessWithUID(UInt_t uid, void *obj):

   Int_t pid = (uid>>24)&0xff;
   <...>
  (TProcessID*)fgPIDs->At(pid);

so when the PID index reaches 256, pid overflows to 0. Since pid=0 is the TProcessID of the current session, there can be only an extra 255 PIDs in use before the index overflows. This would also explain why the processID of the current session is also written into the corrupted file.

I would appreciate it if some people knowledgeable with the inner workings of TRef's could comment if this is indeed the problem or not. If it is, is there a different way of merging files with TProcessIDs that does not run into this problem?

Thank you for your help,
- Nicolas Received on Sat Mar 12 2005 - 12:05:27 MET