[issue21351] refcounts not respected at process exit

STINNER Victor added the comment: Never rely on the GC. Avoid cycles by using the weakref module. -- ___ Python tracker ___ ___ Python

[issue21351] refcounts not respected at process exit

Min RK added the comment: Thanks for your help and patience. Closing as slightly unfortunate, but not unintended behavior. -- resolution: -> not a bug status: open -> closed ___ Python tracker ___

[issue21351] refcounts not respected at process exit

Tim Peters added the comment: There's no way to influence finalization order for objects in cycles, and there never was. So nothing actually changed in that respect ;-) What did change is that Python used to forcibly break many module-level cycles in a way that just happened to result in the

[issue21351] refcounts not respected at process exit

Min RK added the comment: Thanks for clarifying that there is indeed a reference cycle by way of the module, I hadn't realized that. The gc blocking behavior is exactly why I brought up the issue. The real code where this causes a problem (rather than the toy example I attached) is in pyzmq,

[issue21351] refcounts not respected at process exit

Tim Peters added the comment: After more thought, I don't think the user can do anything to influence finalization order in cases like this, short of adding "del" statements (or moral equivalents) to break cycles before the interpreter shuts down. Fine by me ;-) Something CPython could do, wh

[issue21351] refcounts not respected at process exit

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue21351] refcounts not respected at process exit

Tim Peters added the comment: I think Antoine is right on all counts. The most surprising bit may be that p, c, and c2 are in reference cycles, but - surprising or not - that's always been true. The reason "it worked" before 3.4 is that CPython happened to break the cycles via the nasty hack

[issue21351] refcounts not respected at process exit

Antoine Pitrou added the comment: Looking into it, it's normal for refcounts to be "ignored": those objects belong to reference cycles: tstgc.__dict__ -> p (or c, or c2) -> p.__class__ (i.e. Parent, or Child respectivel)) -> Parent.__dict__ -> Parent.__del__ (or Parent.__init__, or Parent.child

[issue21351] refcounts not respected at process exit

Antoine Pitrou added the comment: (the 3 kinds of output are probably due to hash randomization) -- ___ Python tracker ___ ___ Python-

[issue21351] refcounts not respected at process exit

Changes by Tim Peters : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue21351] refcounts not respected at process exit

Tim Peters added the comment: Just noting that, for me, the problem goes away if del c, c2 is added as the last line of the test. This suggests the problem is due to changes in end-of-life module cleanup. Without that line, I see 3 kinds of output: 1. del child del child del parent parent d

[issue21351] refcounts not respected at process exit

Nathan Stocks added the comment: This affects me as well. I have to manually clean up objects in the correct order in script I am working on under 3.4.0. I have this problem under both OS X 10.9.2 Mavericks and under CentOS 6.5 -- nosy: +nathan.stocks ___

[issue21351] refcounts not respected at process exit

New submission from Min RK: Reference counts appear to be ignored at process cleanup, which allows inter-dependent `__del__` methods to hang on exit. The problem does not seem to occur for garbage collection of any other context (functions, etc.). I have a case where one object must be cleaned