REST version : v2.2.13
REST commit : 9091c350
If I try to apply TRestHitsRotateAndTraslateProcess I get a floating point exception:
I am using the same parameters I used with REST v2.1.X, where I had no problems with this process. My configuration files are signalToTrackCris.rml (4.2 KB) and processes.rml (19.9 KB)
Do you see what I’m doing wrong?
That process is very rarely used, and I never tested myself. Looking inside I just guessed how it should be in the new V2.2.X. And I pushed to the repository a new commit.
I am not sure if that would solve this problem, but there were not good practices in the old version. Check it. If that does not solve the problem, try writing few debugging lines inside the ProcessEvent method, and inside RotateIn3D, and Translate methods itself.
Hello,
After doing some debugging I still can’t find the problem. In TRestHitsRotateAndTraslateProcess.cxx, I’ve commented some lines to leave only the absolutely necessary, so the process does nothing, but it still expodes. The crash happens just after fOutputEventInitialize.
This is the process: TRestHitsRotateAndTraslateProcess.cxx (5.4 KB) . The output of running restManager is Debug_output.txt (13.2 KB) . And in case it’s helpful, I attach other files where I’ve written the relevant cout for debuggin purposes: TRestEvent.cxx (7.3 KB) , TRestEventProcess.cxx (15.7 KB)
I find the bug in this process: line 102:
*fOutputHitsEvent = *fInputHitsEvent;
We shouldn’t use this kind of copying because TRestHitsEvent contains pointer. With this kind of copyings, you make fHits datamember in the two TRestHitsEvent objects pointing to a same address, and will cause double free corruption when deleting them.
The solution is to change this line into:
fOutputHitsEvent = fInputHitsEvent
Ok, thanks @nkx , the problem was solved! In addition, I fixed another bugs related to TRestHits::GetMeanPosition and TRestHits::Rotate3D. Please, @CMargalejo, have a look at the following commit. There were problems related to the fact that some components of the vector were nan when rotating them, and there was division by zero.
Eventhough I understand the reason now, I am confused with the fact that sometimes we are able to use *out = *in, and other times not.
I am confused, because some times we are transferring the contents *x, and other times we are just transferring the pointer. Will this not cause a problem in some scenarios?
I see you commented the following line inside the process.
\\ fInputHitsEvent->CloneTo(fOutputHitsEvent);
Is this the right way to copy the content from input to output? Then, there are some cases where we need to do that? Or why using one scheme or the other?
In other words, It is possible to adopt one or the other in any process? Should we use the copy more often even if that carries memory copy time consumption?
if the event doesn’t contain pointer that is explicitly called “delete” in its destructor, then it is safe to use “*out = *in”. TRestRawSignalEvent is one example. On the other hand, in TRestHitsEvent, we delete fHits in tis destructor, so it is bad.
For the moment I think we just need to copy the address with simply out = in. Using *out = *in or out->CloneTo(in); we transfer all the data of in to a new place, but I don’t find any case for such operation.