Hello everybody,
After reading the TRef explanation again, I’m still stuck with the following. I’m looking at a ROOT file, created in one pass and containing TRef’s. If I have a look at the fUniqueID’s of all the referenced objects, there’s one type that stands out. All the ‘normal’ objects in TClonesArray branches return the fUniqueID they were saved with, a reasonable, ‘hundreds’ number. There is, however, one branch of TMBCellContainer’s, these objects are TRef’d and somehow return strange values for their fUniqueID. This can be seen below, the value in the second column is the ‘correct’ value. I know that the 8 MS bits encode the pid but I don’t understand why these objects seem to have different pid’s. (In the cases in which the first column shows a zero, there were no objects referencing the TMBCellContainer in this event.)
Note that especially entry #32 is problematic, since this one will insert the object at entry zero in the object list and after that all TRef’s with fUniqueID==0 will return this object.
I’m using ROOT v4.02/00 together with gcc 3.4.3 on a Fedora Core 1 machine.
[code]root [6] t->Scan(“CaloCells.fUniqueID:CaloCells.fUniqueID&0xffffff”,"","")
- Row * CaloCells * CaloCells *
-
0 * 0 * 0 * -
1 * 16777329 * 113 * -
2 * 155 * 155 * -
3 * 0 * 0 * -
4 * 140 * 140 * -
5 * 16777387 * 171 * -
6 * 0 * 0 * -
7 * 192 * 192 * -
8 * 68 * 68 * -
9 * 16777399 * 183 * -
10 * 111 * 111 * -
11 * 0 * 0 * -
12 * 16777578 * 362 * -
13 * 0 * 0 * -
14 * 119 * 119 * -
15 * 118 * 118 * -
16 * 16777398 * 182 * -
17 * 163 * 163 * -
18 * 114 * 114 * -
19 * 189 * 189 * -
20 * 16777341 * 125 * -
21 * 151 * 151 * -
22 * 174 * 174 * -
23 * 16777336 * 120 * -
24 * 132 * 132 *
Type to continue or q to quit ==>
-
25 * 93 * 93 * -
26 * 16777317 * 101 * -
27 * 103 * 103 * -
28 * 94 * 94 * -
29 * 16777356 * 140 * -
30 * 144 * 144 * -
31 * 169 * 169 * -
32 * 16777216 * 0 * -
33 * 98 * 98 * -
34 * 428 * 428 *
(long long)35
[/code]