Mike Keith

Catch another case where object reference isn't tracked

Right - I agree that it should work, but I checked the swig generated wrap_psrchive.cxx file and it really just never made the call. Checking a few other calls to constructors it also seemed missing. It does appear in the "factory methods" like load_Archive() etc. I don't think it's a change in swig though as I'm pretty sure it failed with one built using an old swig version. Anyway at least our immediate issue is solved (i.e. we can run our pipelines again) but for sure it would be good to solve...

ProfileShiftFit segfaults from python interface (or external code)

Surprisingly, the reference tracking feature already exists in the python interface, but it doesn't track the reference to all objects. Explicitly telling it to track ProfileShiftFit fixes the immediate bug, though likely other objects also need to be explicitly tracked. Fixed in 209acda05

Fix for bug #495

ProfileShiftFit segfaults from python interface (or external code)

ProfileShiftFit segfaults from python interface (or external code)

Just trying to work out how serious this is in terms of reprocessing large volumes of data for the MeerTime TPA. Can anyone say if this only affects in the frequency direction or might the delays also change with time - e.g. is it possible that different subints will have different offsets. Obviously if there is something that changes from pulse-to-pulse in the single-pulse data then it is more serious than if it's just that the dedispersion is wonky +/- 1 bin. (though probably we should reprocess...