You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that this issue is more of a write-down for myself for when I start to work on this again, as I currently do not have the time to do so.
Deleting a widget via SubMenu.delWidget() causes the widget object itself to stay around, causing a memory leak.
Preliminary testing with the testbtn widget (an ImageButton) has revealed that this is probably caused by a cyclic dependency, as sys.getrefcount() of the widget just before deleting the last known reference returns 10. However, gc.get_referrers() shows 7 results, three frame objects, one cell object, one bound method BasicWidget.on_mouse_release of the button in question, a weird 5-tuple of form (obj,285,407,1,16) and a large dictionary containing lots of OpenGL constants and function pointers.
The 5-tuple's second and third item have been seen to change slightly over several tests, but the last two remained constant. Perhaps they are constants and the other ones are OpenGL handles? Further testing required...
The dict seems to have lots of keys, and was to large to print out entirely on the console. All visible keys seem to originate from pyglet OpenGL constants and functions, though there were some odd keys like PFNGLGETNAMEDRENDERBUFFERPARAMETERIVEXTPROC which I have never heard of and that lack the typical gl* schema.
This dict could be the locals/globals of some module, should check what module specifically, maybe by writing the list of keys to a file and searching manually...
Should also check under what key the widget is available in this dict.
The best way to solve this problem seems to be to find all referrers to the widget and eliminate them as cleanly as possible.
Checklist:
Check the origin of the frame and cell objects, just in case
Reverse search the numbers of the 5-tuple for OpenGL or other constants
Manually check all keys of the large dictionary to try and find any out-of-the-ordinary keys
Find out why the bound method on_mouse_release still exists, and not the others
The text was updated successfully, but these errors were encountered:
Note that this issue is more of a write-down for myself for when I start to work on this again, as I currently do not have the time to do so.
Deleting a widget via SubMenu.delWidget() causes the widget object itself to stay around, causing a memory leak.
Preliminary testing with the testbtn widget (an ImageButton) has revealed that this is probably caused by a cyclic dependency, as sys.getrefcount() of the widget just before deleting the last known reference returns
10
. However, gc.get_referrers() shows 7 results, three frame objects, one cell object, one bound methodBasicWidget.on_mouse_release
of the button in question, a weird 5-tuple of form(obj,285,407,1,16)
and a large dictionary containing lots of OpenGL constants and function pointers.The 5-tuple's second and third item have been seen to change slightly over several tests, but the last two remained constant. Perhaps they are constants and the other ones are OpenGL handles? Further testing required...
The dict seems to have lots of keys, and was to large to print out entirely on the console. All visible keys seem to originate from pyglet OpenGL constants and functions, though there were some odd keys like
PFNGLGETNAMEDRENDERBUFFERPARAMETERIVEXTPROC
which I have never heard of and that lack the typical gl* schema.This dict could be the locals/globals of some module, should check what module specifically, maybe by writing the list of keys to a file and searching manually...
Should also check under what key the widget is available in this dict.
The best way to solve this problem seems to be to find all referrers to the widget and eliminate them as cleanly as possible.
Checklist:
on_mouse_release
still exists, and not the othersThe text was updated successfully, but these errors were encountered: