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

From: Rene BRUN <>
Date: Sat, 12 Mar 2005 12:38:31 +0100 (MET)

Hi Nicolas,

This limitation has been removed a few weeks ago in the development version.
see (see TRefs/TObject)

see also the development notes at :

2005-01-28 06:45 brun

Specifically, fUniqueID can now store the ProcessID indentifier 0 through 254. When more identifiers are used, then instead of store the identifier in the 8 higher bit of fUniqueID we store in a table (TProcessID::fgObjPIDs) linking addresses to pids.

Rene Brun

On Sat, 12 Mar 2005,
Nicolas Berger wrote:

> 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:38:37 MET

This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:45:06 MET