This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients David Ford (FirefighterBlu3), martin.panter
Date 2017-02-15.10:33:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1487154798.12.0.5523006941.issue29564@psf.upfronthosting.co.za>
In-reply-to
Content
You say that the line number is incorrect. What would you consider a correct line number to be?

Let me try again to explain my theory about garbage collection and reference cycles. Perhaps you have two objects a and b, linked such that a.x = b and b.y = a. This is a reference cycle. Suppose that the socket is also attached e.g. as the attribute a.socket. Even if all functions have deleted their references to a and b and the socket, the interpreter does not immediately realize that a and b (and therefore the socket) can be cleaned up and released from memory.

At some arbitrary point after everything has released its reference to a, b, and the socket, the interpreter will run the garbage collecter. It will pull apart the reference cycle, call the socket’s destructor, and trigger the warning. So I would expect that the line number that happened to trigger the garbage collector is indeed as reported. It is just not very useful in your case.

Please try calling gc.collect() at some point before just before the line indicated in the warning. That should force the warning to be emitted as part of the garbage collector run, and indicate that was indeed the indicated line that was triggering the warning.
History
Date User Action Args
2017-02-15 10:33:18martin.pantersetrecipients: + martin.panter, David Ford (FirefighterBlu3)
2017-02-15 10:33:18martin.pantersetmessageid: <1487154798.12.0.5523006941.issue29564@psf.upfronthosting.co.za>
2017-02-15 10:33:18martin.panterlinkissue29564 messages
2017-02-15 10:33:17martin.pantercreate