Any idea on why i’d get a memory trap (like this stacktrace shown in the screenshot) : when trying to delete an item I’ve checked as not null (via the second screenshot)?
FreeRTOS stack overflow?
FreeRTOS Stack overflow caused by lv_obj_del?
I’ll monitor memory some and see if i can reproduce at least.
Thanks for the input
It can happen if the functions were nested too deeply and/or there was larger local variable somewhere.
In project with UI with average complexity I measured that 2048 words of stack was enough, so I suggest setting it to 4096 to be sure.
Moved my UI code back over to the PC simulator demo - and may have found some hint (or just found other errors in my code)… At least this will take FreeRTOS out of the question:
Not sure how to interpret this - do I have an alignment error here? (I thought that alignment was managed with LV_ATTRIBUTE_MEM_ALIGN
?
READ of size 1 at 0x000101f54c83 thread T0
#0 0x1019f0f59 in lv_draw_map lv_draw_img.c:433
#1 0x1019eca47 in lv_img_draw_core lv_draw_img.c:276
#2 0x1019eab89 in lv_draw_img lv_draw_img.c:84
#3 0x1017cb719 in draw_img lv_img.c:628
#4 0x1017bbe86 in lv_img_event lv_img.c:485
#5 0x101aa8e42 in lv_obj_event_base lv_event.c:96
#6 0x101aa79f2 in event_send_core lv_event.c:378
#7 0x101aa734d in lv_event_send lv_event.c:73
#8 0x101b72bee in lv_refr_obj lv_refr.c:685
#9 0x101b7325d in lv_refr_obj lv_refr.c:721
#10 0x101b7325d in lv_refr_obj lv_refr.c:721
#11 0x101b7325d in lv_refr_obj lv_refr.c:721
#12 0x101b722b7 in lv_refr_obj_and_children lv_refr.c:622
#13 0x101b71742 in lv_refr_area_part lv_refr.c:555
#14 0x101b6f7e7 in lv_refr_area lv_refr.c:467
#15 0x101b6a8a0 in lv_refr_areas lv_refr.c:389
#16 0x101b65368 in _lv_disp_refr_timer lv_refr.c:216
#17 0x10189503d in lv_timer_exec lv_timer.c:315
#18 0x10189455e in lv_timer_handler lv_timer.c:106
#19 0x101c28889 in main main.c:106
#20 0x7fff6b148cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)
0x000101f54c83 is located 3 bytes to the right of global variable 'warning_icon_map' defined in '../lv_demos/src/amx_ui/assets/s6_warning_icon.c:16:96' (0x101f54c80) of size 0
'warning_icon_map' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow lv_draw_img.c:433 in lv_draw_map
Shadow bytes around the buggy address:
0x1000203ea940: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
0x1000203ea950: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x1000203ea960: f9 f9 f9 f9 00 00 00 00 00 00 00 00 f9 f9 f9 f9
0x1000203ea970: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00
0x1000203ea980: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
=>0x1000203ea990:[f9]f9 f9 f9 00 00 00 00 00 00 00 00 f9 f9 f9 f9
0x1000203ea9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000203ea9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000203ea9c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000203ea9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000203ea9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
(lvgl
and lv_drivers
both on last release/v8.0
commit, lv_port_pc_eclipse
on tag v8.0.0
)
neveremind - this was on me when porting to simulator, i forgot to update the color depth from 32 to 16. after that this went away