New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
__del__() order is broken since 3.4.0 #67908
Comments
Pythons prior to 3.4.0 print Vector! while >=3.4.0 print Device! If we replace Main with Vector on line 21, the behavior becomes random: in 50% of all cases it prints the wrong sequence, in other 50% the right. Our team treats this as a bug for several reasons:
This may have something to deal with the implementation of PEP-442 (though in our case there no reference cycles at all). |
+1 |
Actually there *is* a cycle: A workaround is to not store objects with __del__ in module globals... |
Amaury is right. In your case you could keep track of the Vectors in the Device object and invalidate them when the Device is destroyed (using e.g. a WeakSet). Or Vector could delegate its destruction to Device, e.g.: class Device(object):
destroyed = False
def __del__(self):
self.destroyed = True
def _dealloc_vector(self, v):
if not self.destroyed:
...
class Vector(object):
def __init__(self, device):
self.device = device
def __del__(self):
self.device._dealloc_vector(self) |
Ok, even assuming that all module globals are in circular reference starting with python 3.4, here is another example without using the globals: Brief description: |
There is a cycle for every class with a method. >>> class A:
... def __del__(self): pass
...
>>> A.__del__.__globals__['A']
<class '__main__.A'> |
There is a cycle involving the class object, but I don’t think there is a cycle involving the instance objects this time. However, I wonder if __del__() is meant to be called in any particular order anyway. What’s to stop the garbage collector itself from creating a temporary reference to the Device instance, destroying the Vector instance, which invokes Vector.__del__(), and finally destroying the temporary reference to the Device instance? |
Alexey, you're right that in this case (bug2.py) the cyclic GC is a bit less friendly than it was. It's not obvious there's a way to change that without introduce a lot of complexity. I'll try to take a look some day, although others may help too :-) That said, my advice in msg238680 still holds. When you're writing a Python wrapper around a C or C++ library with well-defined ownership relationships, I think you should enforce those in the Python wrapper as well (that's my experience with llvmlite, anyway). |
It is. >>> a = A()
>>> a.__class__.__del__.__globals__['a']
<__main__.A object at 0xb702230c> And all objects referenced from user class or module level instance of user class are in a cycle. This problem can cause issues such as bpo-17852. |
But in the case of bug2.py, “a” is a variable inside main(), not a global variable. BTW I take back my second paragraph questioning the whole order thing; I clearly didn’t think that one through. |
Yes, in bug2.py we have different cycle. a ↔ b a and b are in a cycle, and therefore v and d are in cycle. I think that in such case v always should be destroyed before d, independently of a cycle that refers them. And this is the same situation, as for io classes. A TextIOWrapper object refers a BufferedWriter object, a BufferedWriter object refers a FileIO object. and some cycle refers a TextIOWrapper object. As a result a FileIO object can be closed before a TextIOWrapper object or a BufferedWriter object flush its buffer. |
Can this be closed as not-a-bug. |
While this is not a bug, Antoine said he might look at improving the situation, so I leave it to him to close it or not. |
There seems to be agreement that this is not a bug, and there's been no activity on this issue for 7 years. I'm therefore closing the issue. If any of the participants are still interested in working on this problem, they're obviously free to reopen the issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: