Not use the lv_obj_is_valid() in ui_theme_manager.c

kanbaiStaok · July 31, 2024, 6:33am

What do you want to achieve?

this API is not safe, see:

lv_obj_is_valid is not safe to use this way. It can happen that a widgget wwas freed and on it’s exact memory address an other
widget was allocateed.
lv_obj_is_valid will say that it’s valid, but it’s still not the widget thit you wanted.

and Alternative solutions for the implementation of lv_obj_is_valid() · Issue #6395 · lvgl/lvgl · GitHub

this API is very easy lead to crash, so I manually deleted this, like:

What have you tried so far?

Screenshot or video

Others

SquareLine Studio version:
Operating system:
Target hardware:

Hermit · August 1, 2024, 10:53pm

We know about the post you linked, the current limitation of LVGL about checking validity of objects, and the possibility that a new object very rarely (according to LVGL authors) takes the memory-location of the old one. That’s why we use NULL-checking beside lv_obj_is_valid(). By removing lv_obj_is_valid() you just lose an extra check I think. But thanks for pointing it out that there’s a new pointer auto-nullifying function just added to LVGL which is to circumvent this object-validity check discrepancy in the future.

kanbaiStaok · August 2, 2024, 1:22am

Discussion on the replacement of this API

github.com/lvgl/lvgl

Alternative solutions for the implementation of lv_obj_is_valid()

opened 05:40PM - 19 Jun 24 UTC

closed 01:52AM - 24 Jul 24 UTC

bhspyder

stale

### Introduce the problem The function lv_obj_is_valid() as it is currently i…mplemented searches every object (and it's chidren recursively) in every screen on every display looking for a match. This does not scale well on big projects, especially if all of the screens and objects are created on bootup and exist for lifetime of the application. I ran into this performance bottleneck while using the theme support provided by SquareLine studio generated code (I understand SquareLine is not affiliated with LVGL any more so this is more of an aside) which uses lv_obj_is_valid() to check for valid objects in it's theme style linked list. Are there any alternative solutions that can be considered to improve the performance of this function? ### Proposal One idea that came to mind (probably a bad idea) would be to NULL obj->class_p in the lv_obj_destructor() and changing lv_obj_is_valid() to something like this: ``` bool lv_obj_is_valid(const lv_obj_t * obj) { if (obj == NULL) { return false; } return lv_obj_has_class(obj, &lv_obj_class); } ``` Things to consider: * Accessing dangling pointers is a bad idea * If the object was deleted and the freed block of memory was unused, it's class_p would be NULL and be considered invalid. * If the object was deleted and the block of feed memory was reused by another lv_obj_t starting at the same offset, it would have a valid class_p and be considered valid. * If the object was deleted and the block of freed memory was reused by something else or an lv_obj_t with a different offset, the odds of the data lining up to produce a valid class_p that is or inherits from lv_obj_class are low, but not impossible? * This would only indicate that the obj has not been deleted, it would not indicate that the obj was a screen or a child of a screen. Since following base_class pointers to check for lv_obj_class inheritance on potentially freed obj pointers is not a good idea, comparing obj->class_p to a list of valid class pointers instead of using lv_obj_has_class() may be better, but still not good. This solution was only provided to get a discussion going. Please suggest alternative solutions.

Hermit · November 16, 2024, 10:31pm

Find my latest thoughts about this here: