Really appreciate you looking into this and, as an aside, I really love your work with this graphics library!
The location of the change also confused me, as it isn’t the method I’m calling, so I added
LV_LOG_WARN(text) to both
lv_label_set_text_static to get a better trace output of what is flowing where. I used you test above and saw the text info printed from just
lv_label_set_text_static but for my code I saw it output from both
lv_label_set_text. On further investigation, the key point seems to be the comment I made above as an “aside” in that I said “I should add that the label I am refreshing is the label part of a textarea”. When I change your example to:
lv_obj_t * ta = lv_textarea_create(lv_scr_act(), NULL);
lv_obj_t * label = lv_textarea_get_label(ta);
lv_label_set_text_static(label, "aaaaaaaaaaaaaaaa veryyyyyyyyyyyyyyyy loooooooooooooooooooog teeeeeeeeeeeeeeeeeext");
lv_label_set_text_static(label, "aaaaaaaaaaa veryyyyyyyyyyyyyyyy loooooooooooooooooooog teeeeeeeeeeeeeeeeeext");
I see that both
lv_label_set_text_static and then
lv_label_set_text log the text, so that explains why that issue occurs in the
lv_label_set_text method, something to do with the label in a text area.
Your example code still works, as the size of the text isn’t enough to exceed the memory allocated to LVGL, I’d guess, but when I throw a couple of large-ish (4k - 100k) char buffers at
lv_label_set_text_static, it breaks when it enters
lv_label_set_text with the Nov 21st commit.
I guess something related to the textarea must be “signalling” to call ‘lv_label_set_text’? The change made in
lv_label.c to remove the
return statement as part of the condition
if(text == NULL) around line 188 causes execution to continue into
lv_label_set_text, which then OOMs due to the large size of the static buffer.
Thanks again for looking into this!