On my esp32-3248S035C, after entering the IP address, I was seeing a
segfault at
lv_mem_free at .pio/libdeps/esp32-3248S035C/lvgl/src/misc/lv_mem.c:179
allocate_btn_areas_and_controls at .pio/libdeps/esp32-3248S035C/lvgl/src/widgets/lv_btnmatrix.c:877
lv_btnmatrix_set_map at .pio/libdeps/esp32-3248S035C/lvgl/src/widgets/lv_btnmatrix.c:94
lv_keyboard_update_map at .pio/libdeps/esp32-3248S035C/lvgl/src/extra/widgets/keyboard/lv_keyboard.c:397
lv_keyboard_set_mode at .pio/libdeps/esp32-3248S035C/lvgl/src/extra/widgets/keyboard/lv_keyboard.c:185
keyboard_event_ip_entry(_lv_event_t*) at src/ui/ip_setup.cpp:81
event_send_core at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_event.c:467
lv_event_send at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_event.c:63
lv_keyboard_def_event_cb at .pio/libdeps/esp32-3248S035C/lvgl/src/extra/widgets/keyboard/lv_keyboard.c:308
event_send_core at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_event.c:467
lv_event_send at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_event.c:63
lv_btnmatrix_event at .pio/libdeps/esp32-3248S035C/lvgl/src/widgets/lv_btnmatrix.c:520
lv_obj_event_base at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_event.c:91 (discriminator 1)
event_send_core at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_event.c:458
lv_event_send at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_event.c:63
indev_proc_release at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_indev.c:970
indev_button_proc at .pio/libdeps/esp32-3248S035C/lvgl/src/core/lv_indev.c:808
lv_timer_exec at .pio/libdeps/esp32-3248S035C/lvgl/src/misc/lv_timer.c:313
set_screen_brightness() at src/core/lv_setup.cpp:191
ip_init() at src/ui/ip_setup.cpp:239
setup() at src/main.cpp:28
loopTask(void*) at /home/user/etc/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:41
This seems to be due to a free-after-free. The solution here is to
potentially change the keymap before running the rest of the logic,
because the later logic may tear down the context.
This change also only changes the keyboard mode on focus change, to
avoid running this code on the many un-related events that this handler
gets called for.
I was frequently seeing the following and a reboot:
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x4008ae2d PS : 0x00060330 A0 : 0x800d3fd9 A1 : 0x3ffe15f0
A2 : 0x3ffc40e8 A3 : 0x00000000 A4 : 0x000000ff A5 : 0x0000ff00
A6 : 0x00ff0000 A7 : 0xff000000 A8 : 0x00000000 A9 : 0x3ffe15c0
A10 : 0x3ffc40e8 A11 : 0x3f40035d A12 : 0x3ffe16a0 A13 : 0x000004b0
A14 : 0x7ff00000 A15 : 0x7ff2c000 SAR : 0x0000001d EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x4008ae2d LEND : 0x4008ae41 LCOUNT : 0xffffffff
Backtrace: 0x4008ae2a:0x3ffe15f0 0x400d3fd6:0x3ffe1600 0x400d42d3:0x3ffe18f0
decoded:
0x4008acbc: strcmp at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strcmp.S:467
0x400d4145: fetch_printer_data() at /home/user/tmp/CYD-Klipper/CYD-Klipper/src/core/data_setup.cpp:180
0x400d42d3: data_loop_background(void*) at /home/user/tmp/CYD-Klipper/CYD-Klipper/src/core/data_setup.cpp:233 (discriminator 1)
Seems like the printer state was frequently ending up as null, so check
for that and return a reasonable response. After applying this patch,
things are stable for me.
Flaviu Tamas