[issue43383] imprecise handling of weakref callbacks

Change by Konrad Schwarz : -- resolution: -> postponed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python

[issue43383] imprecise handling of weakref callbacks

Konrad Schwarz added the comment: Unfortunately, my management has impressed other priorities upon me; I can't delve deeper into this subject at the moment. My takeaway is that the error very likely lies on my side; maybe I need to re-check local variables and del them explicitly. In any ca

[issue43383] imprecise handling of weakref callbacks

Tim Peters added the comment: This won't go anywhere without code (preferably minimal) we can run to reproduce the complaint. If there were a "general principle" at work here, someone else would surely have reported it over the last few decades ;-) To the contrary, the common confusion is in

[issue43383] imprecise handling of weakref callbacks

Mark Dickinson added the comment: One more thing: I'm assuming that everything in sight is single-threaded? With more than one Python thread (even if that thread is auxiliary to anything you're doing - e.g., if you're working at an IPython prompt, there will likely be at least a couple of ex

[issue43383] imprecise handling of weakref callbacks

Mark Dickinson added the comment: Have you tried doing a "gc.get_referrers" on your weakref, to verify that there aren't any references that you don't expect to be there? Another diagnostic would be to run with cyclic garbage collection disabled (via gc.disable). If you're seeing different b

[issue43383] imprecise handling of weakref callbacks

Konrad Schwarz added the comment: > If I understand correctly, the reported bug is that you're seeing a weakref > callback being executed > after the weakref.ref instance it's attached to is deleted. Is that correct? Exactly. I del what should be the only reference to the weakref.ref/proxy,

[issue43383] imprecise handling of weakref callbacks

Mark Dickinson added the comment: If I understand correctly, the reported bug is that you're seeing a weakref callback being executed after the weakref.ref instance it's attached to is deleted. Is that correct? Do you have a minimal example we can use to reproduce the effect? Without such a

[issue43383] imprecise handling of weakref callbacks

New submission from Konrad Schwarz : I am seeing the following non-deterministic behavior: My code processes DeviceTree, a tree-based specification format for hardware descriptions, that includes cross-references ("phandles"). For all intents and purposes, this format is similar to XML; phan