Description
When assigning a static buffer to a label via:
lv_label_set_text_static(lbl_taLogfile, bufLogfile);
Receive an out of memory error. This occurs when trying to assign a larger buffer to the label after previously assigning a smaller buffer. If the new assignment is a smaller buffer than the previous one, everything is fine. There were no issues with this in 7.7.1, but it now occurs in 7.7.2 (when error condition was discovered in 7.7.2, replaced lv_label.h and lv_label.c from 7.7.1, recompiled and issue went away)
What MCU/Processor/Board and compiler are you using?
PlatformIO in VSCode, targeting Teensy 4.1
What do you experience?
WARNING: #208: lv_mem_alloc: Couldnât allocate memory
ERROR: #233: lv_label_set_text: lv_label_set_text
ERROR: #127: lv_debug_log_error: Out of memory (0x00000000)
What do you expect?
No out of memory error - worked in prior release, and purpose of assigning static text is to avoid LVGL memory issues 
Could you bisect to find which commit causes the issue? I cannot see anything but bugfixes in the git history.
Thanks for the response. I realized that the version numbers might not be accurate as I tend to grab the latest code when needed and the version numbers arenât always reflective of the latest codeâŚ
Anyway, for lv_label.c, the committed version through Nov 11th does not have my issue. The committed version on Nov 21st does have this issue. Specifically, it is this change:
âWorkingâ code present in Nov 11th commit @ line 188:
/*If text is NULL then refresh */
if(text == NULL) {
lv_label_refr_text(label);
return;
}
In the Nov 21st commit, which exhibits my issue, this was changed to:
/*If text is NULL then just refresh with the current text */
if(text == NULL) text = ext->text;
If I revert back to the code snippet from Nov 11th that uses lv_label_refr_text, I do not get an out of memory issue when calling lv_label_set_text_static with a larger buffer.
Thanks for the help!
I should add that the label I am refreshing is the label part of a textarea. I wish to display log files within my app in a scrollable textarea, and these can grow to several hundred Kb, easily exhausting the standard RAM on a Teensy 4.1. But I have an 8Mb PSRAM chip soldered to the Teensy 4.1, so I load the log file into a buffer assigned to PSRAM and use that as the static buffer for the label associated with the textarea.
Hi,
Iâve tried to reproduce the issue but I couldnât. 
With this code:
lv_obj_t * label = lv_label_create(lv_scr_act(), NULL);
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");
there was no memory allocation in any of lv_label_set_text_static calls which seems logical as your issue happened in lv_label_set_text and not in lv_label_set_text_static.
Could you attach your lv_conf.h and a few lines of code to reproduce the issue?
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!
.
Okay; I think I may see the problem here now that you word it that way. It probably needs to track whether lv_label_set_text or lv_label_set_text_static should be called. Right now I think it just ends up switching back to dynamic buffers.
Ok, great, let me know if you need more info or want me to test any fixes, etc.
@kisvegabor It seems to me that it is impossible to support Arabic text connections on a static buffer, because we need to process the text first. Should your change be conditioned on the buffer not being static?
Sorry for the late reply.
I see whatâs the issue now and started to fix it but I realized that itâs not reasonable to force an uneditable text in the text area because itâs completely against its purpose.
If your goal is only the have a scrollable static text you can simply create an lv_page and create the label on it. Could it work your you?
1 Like
Yes, per your suggestion, just tried that and recreated what I need. This was more of a rabbit-hole decision tree - textarea was the easiest way to show scrollable text, but it OOMâd on large text, so decided to grab the label for the textarea, and set text via the static textâŚbut this way probably makes more sense, as I donât need to edit the text.