Bug #1858

InputCppRootData use can lead to an error from TRefArray about the process ID

Added by Dobbs, Adam almost 8 years ago. Updated almost 8 years ago.

Code Infrastructure
Target version:
Start date:
22 June 2016
Due date:
% Done:


Estimated time:
New Issue


When using InputCppRootData to pull MAUS data back into MAUS, it is possible to get the following type of error message:

Error in <TRefArray::AddAt>: The object at 0x1018ae50 is not registered in the process the TRefArray points to (pid = ProcessID0/049c33d0-389a-11e6-9717-9ed3c69bbeef)

No data is then produced. It is hinder the Global guys.

Related issues

Related to MAUS - Bug #1856: InputCppRootData overflows the ref counterClosedRogers, Chris13 June 2016


Updated by Dobbs, Adam almost 8 years ago

OK, after consulting I think it worth trying swapping the TRefArrays (one process ID supported) to std::vector<TRef*> s (multiple process IDs suported, one per TRef). Jan could you try this and let me know?


Updated by Dobbs, Adam almost 8 years ago

Update: swapping to std::vector<TRef*> is not so simple as there does not seem to be a TRefProcessor class written. Chris R, could you advise - do you away of using std::vector<TRef*> in the MAUS processor framework?


Updated by Rogers, Chris almost 8 years ago

Is the problem arising during conversion from Json to C++? The TRefProcessor would only be called during conversion. I rather thought the issue was in serialisation/deserialisation of the ROOT tree and Json has nothing to do with it.

I don't know how ROOT does TRef* - one way to do it (not using TRef* but doing something very equivalent) would be to
  • make an area in the data tree which is like std::set<TObject*> references;
  • invent a MAUSRef* (perhaps some stl object exists like std::auto_ptr)
  • someone makes a MAUSRef* we dump the actual data in std::map<TObject*, size_t> (TRefProcessor does this I guess)
  • Only one pointer to the MAUSRef* does a look up on the std::map during dereference operation, so ROOT only ever stores one instance of the target object (from the std::map).
  • Reference counting could be implemented and then this becomes a full smart pointer set up.

Hope that makes some sense. Probably ROOT already does this for us, if we only knew how to get the TRef thing to work.


Updated by Dobbs, Adam almost 8 years ago

Hi Chris,

Thanks, yes, this is trying to create a processor for doing JSON / Cpp conversion. It is not necessary for what we want to do (ROOT I/O) however I assumed the MAUS framework requires it. Let me explain more fully:

  • TRefArray is used by the Global data structure to provide cross-links (MAUS policy) to prevent data replication in the final ROOT file
  • TRefArray have to contain objects created by the same process ID. When Jan or whoever runs MAUS several times and updates the data containers the TRefArray has a hissy fit due the different process IDs
  • The ROOT way of dealing with this is to switch out the TRefArrays in favour of std::vector<TRef*>s (less efficient, but no problems with different PIDs as each TRef* has its own PID)

So far so good. Jan has changed his data structure to use std::vector<TRef*>, however when we tried to update the corresponding JsonCppProcessor in MAUS, by adding a PointerArrayProcessor<TRef*> member to the Global TrackProcessor, we found that there was no TRefProcessor to process TRefs. I have tried writing one but so far unsuccessfully (the existing code handles TRefs and TRefArrays quite different for some reason).

We could try not bothering with updating the JsonCppProcessor, as we don't use JSON anymore anyway, and see if the framework accepts that without too much trouble.

I am not sure I follow your idea about implementing a new type of smart pointer - we need to use TRef's in order to do serialisation/deserialisation for the ROOT file, unless you mean to make a smart pointer to do that instead of TRef (ugh...). C++11 already has nice smart pointers bundled (ref counting), but I don't see what it gains us.


Updated by Dobbs, Adam almost 8 years ago

Update: I tried running without entering the TRef entries into the Global TrackProcessor, got it to compile but it then seg faulted at run time. It seems MAUS running is still bound to JSONCppProcessors...


Updated by Dobbs, Adam almost 8 years ago

  • Status changed from Open to Closed
  • Target version changed from Future MAUS release to MAUS-v2.6.0
  • % Done changed from 0 to 100

Fixed. Turned out to be an error in the GlobalEvent assignment operator, fixed by changing the process ID of the new TRefArray (lhs) to match that of the old (rhs).

Also available in: Atom PDF