ctools

I do have a nice seg fault with fresh code from this morning :

(...)
>>> obs = sim.obs()
>>> del sim
>>> print(obs)
Segmentation fault (core dumped)

For that example, I am not sure what can be done, the way I understand it is that
“del sim” makes obs point to null, but obs still exists in the name space so that
print really tries to print obs.
The only way out that I see would be for “del sim” to also remove obs from the name space,
so that “print obs” would rise a name error. I am not sure how/if that can be done though.

Correction — the script attached does sometimes crash for me, sometimes it doesn’t, which is what you’d expect by accessing GObservations via a dangling pointer. Here’s one crash report: https://gist.github.com/cdeil/013665910cefc6f1ff59

For reference: Johan, Jürgen and I just discussed this and our current understanding is this:

• ctobssim owns the GObservations object, but exposes it as a reference:
  

       mutable GObservations m_obs;              //!< Observation container
  const GObservations & ctobssim::obs    (    void          ) 
  

• obs = sim.obs() creates a Python object that holds a raw pointer to the GObservations object. When sim is deleted, the GObservations object is deleted, leaving obs with a dangling pointer.

This issue can’t be solved in the Python wrapper ... equivalent C++ code would exhibit the same crash (to be verified, I started at https://github.com/cdeil/ctools-checks/tree/master/python_obs_crash).

The core of the issue is that resource management for tool pipelines would have to be changed, so that not one tool is the sole owner of the GObservations object. This could probably be done by using shared pointers to GObservations, i.e. have GObservations not owned by the ctool objects.

We should also investigate how the Fermi ScienceTools solve (or don’t solve) this issue.

It’s possible that we’ll just clarify the docs a bit more, explaining the ownership of GObservations, and postpone this issue post-1.0 or close it as won’t fix.