This repository was archived by the owner on Oct 30, 2026. It is now read-only.
Repository navigation
Runtime: a struct holds one reference to its callback dict; timers and animations release it - #32
Merged
Merged
Conversation
…d animations release it Callbacks set on a struct (lv_anim_t, lv_timer_t, ...) live in a dict in the struct's user_data, like event callbacks. For events the dict is released when the registration ends (#30); for structs nothing released it, so every animation or timer callback leaked (#31). Registry entries now carry the holder that owns the reference. An event registration's holder is NULL and takes one reference per call, as before. A struct's holder is the struct itself: the generated setters pass it as containing_struct (lvgl-bindings), every callback set on the struct shares one reference, and the reference goes when the struct's owner lets go of it: py_lv_struct_dealloc for a struct the Python wrapper owns; LVGL's ext_data free_cb for a timer (lvpy_timer_bind, called after lv_timer_create and lv_timer_set_cb) and for a running animation (lvpy_anim_bind, called after lv_anim_start, where the copy LVGL made takes its own reference so the Python struct can start it again). Those two hooks compile to nothing until lv_conf.h enables LV_USE_EXT_DATA for the CPython build, which the bindings change does. Inert on its own: the generated code calls none of it yet. The sync that follows the bindings change brings the test. Part of #31.
bdbarnett
added a commit
that referenced
this pull request
Oct 12, 2026
* Runtime: a struct holds one reference to its callback dict; timers and animations release it Callbacks set on a struct (lv_anim_t, lv_timer_t, ...) live in a dict in the struct's user_data, like event callbacks. For events the dict is released when the registration ends (#30); for structs nothing released it, so every animation or timer callback leaked (#31). Registry entries now carry the holder that owns the reference. An event registration's holder is NULL and takes one reference per call, as before. A struct's holder is the struct itself: the generated setters pass it as containing_struct (lvgl-bindings), every callback set on the struct shares one reference, and the reference goes when the struct's owner lets go of it: py_lv_struct_dealloc for a struct the Python wrapper owns; LVGL's ext_data free_cb for a timer (lvpy_timer_bind, called after lv_timer_create and lv_timer_set_cb) and for a running animation (lvpy_anim_bind, called after lv_anim_start, where the copy LVGL made takes its own reference so the Python struct can start it again). Those two hooks compile to nothing until lv_conf.h enables LV_USE_EXT_DATA for the CPython build, which the bindings change does. Inert on its own: the generated code calls none of it yet. The sync that follows the bindings change brings the test. Part of #31. * Sync bindings from 2137b6ce8baf4d988a289abef00c7ac3c7b36fb3: animation and timer callbacks are released The generated struct setters now pass the struct as containing_struct, lv_timer_create / lv_timer_set_cb call lvpy_timer_bind and lv_anim_start calls lvpy_anim_bind, and lv_conf.h enables LV_USE_EXT_DATA for the CPython build. With the runtime from #32 that means a callback set on an lv.anim_t lives while the Python struct or a running copy of it exists, and a timer's callback lives while the timer does; LVGL's ext_data free_cb releases them on every path that frees the timer or animation. tests/test_struct_callback_lifetime.py pins it: released after completion once the struct is dropped; survives a dropped struct while running; restart from the same struct; released on anim_delete_all after deleted_cb ran; a timer released on delete, when its repeat count runs out, and when it deletes itself from its own callback; set_cb replaces without leaking; 50 animation plus 50 timer cycles with 20 KB per callback grow the heap by under 64 KB (3 MB before). All nine checks fail on 9.5.50. A variant where the running copy takes no reference segfaults under MALLOC_PERTURB_ while the dropped struct's animation is still running, which is why the copy holds its own reference. For #31.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First of three steps for #31 (animation and timer callbacks never released on CPython). This is the runtime half: registry entries carry a holder; a struct's callbacks share one reference, released with the struct (the Python wrapper's dealloc, or LVGL's
ext_datafree_cb for a timer or a running animation throughlvpy_timer_bind/lvpy_anim_bind). The hooks are inert until the generated code calls them andlv_conf.henablesLV_USE_EXT_DATAfor the CPython build; that is the lvgl-bindings change, and the sync that follows brings the test. The existing 13 tests pass on this commit.