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
and 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_static
and 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, "asd");
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!
.