Bug #1491

Do not crash from Python

Added by Deil Christoph almost 9 years ago. Updated over 8 years ago.

Status:RejectedStart date:06/30/2015
Priority:NormalDue date:
Assigned To:Knödlseder Jürgen% Done:

0%

Category:-
Target version:1.0.0
Duration:

Description

Here an example is given how it’s easy to crash from Python by accessing some object that has gone out of scope:

http://cta.irap.omp.eu/ctools-devel/user_manual/getting_started/python.html
https://github.com/ctools/ctools/blame/1e0ec9e5277097b607d9ed6bae0960e8ba44b16f/doc/source/user_manual/getting_started/python.rst#L267

This should be fixed somehow, i.e. make it impossible or very hard for a user to create a crash from Python.

Actually, with the latest devel version I can’t reproduce the issue with the attached example script!?

Is the example script incorrect?
Has this been fixed in the meantime?
Is there still a way to crash the Python interpreter?

If it’s fixed by now we should just update that docs page.

crash.py Magnifier (471 Bytes) Deil Christoph, 06/30/2015 03:08 PM


Recurrence

No recurrence.

History

#1 Updated by Bregeon Johan over 8 years ago

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.

#2 Updated by Deil Christoph over 8 years ago

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.

#3 Updated by Knödlseder Jürgen over 8 years ago

  • Status changed from New to Rejected

This seems to be more a feature than a bug.

Also available in: Atom PDF