MM specific: random crashes when using global buffer (heap corruption) #104
Description
What happened?
In some setups with "Use global LED buffer" enabled, saving LED settings or changing presets causes a crash.
Workaround
users must manually disabled global buffer in cfg.json:
- open wled-ip/edit
- click on
cfg.json - search for
"ld":true, and change to"ld":false - click "save"
- wait a few seconds, then reboot your wled device
To Reproduce Bug
upload attached cfg.json and presets.json. open LED settings, change number of LEDs --> crash
wled_cfg_WLED-baum.json
wled_presets_WLED-baum.json
Expected Behavior
no crashing
Install Method
Self-Compiled or other
What version/release of MM WLED?
build 2312310
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
this is the best crashdump so far:
---END OF DEBUG INFO---
No data for 1
Re-init busses.
Removing all.
Digital Cleanup.
PIN ALLOC: Pin 2 successfully allocated by LEDs (digital) = 0x82 (130)
Successfully inited strip 0 (len 104) with type 22 and pin 2 (itype 23)
Destroying segment: name=pixel (0x3ffb2b84) [ledsrgb 6 bytes], using global buffer but Segment::_globalLeds is NULL!!
CORRUPT HEAP: Bad head at 0x3ffb32be. Expected 0xabba1234 got 0x00000000
assert failed: multi_heap_free multi_heap_poisoning.c:253 (head != NULL)
Backtrace: 0x400855cd:0x3ffb2520 0x4008e999:0x3ffb2540 0x40094db1:0x3ffb2560 0x40094a07:0x3ffb2690 0x40085a3d:0x3ffb26b0 0x40094de1:0x3ffb26d0 0x400f94d5:0x3ffb26f0 0x400f9616:0x3ffb2730 0x400fcdaa:0x3ffb2780 0x4013e74f:0x3ffb27c0 0x4013eb67:0x3ffb2800 0x401622b9:0x3ffb2820
#0 0x400855cd:0x3ffb2520 in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:402
#1 0x4008e999:0x3ffb2540 in esp_system_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/esp_system.c:128
#2 0x40094db1:0x3ffb2560 in __assert_func at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/newlib/assert.c:85
#3 0x40094a07:0x3ffb2690 in multi_heap_free at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/heap/multi_heap_poisoning.c:253
(inlined by) multi_heap_free at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/heap/multi_heap_poisoning.c:245
#4 0x40085a3d:0x3ffb26b0 in heap_caps_free at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/heap/heap_caps.c:361
#5 0x40094de1:0x3ffb26d0 in free at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/newlib/heap.c:39
#6 0x400f94d5:0x3ffb26f0 in Segment::~Segment() at wled00/FX.h:531
(inlined by) void __gnu_cxx::new_allocator<Segment>::destroy<Segment>(Segment*) at c:\users\frank\.platformio\packages\toolchain-xtensa-esp32\xtensa-esp32-elf\include\c++\8.4.0\ext/new_allocator.h:140
(inlined by) void std::allocator_traits<std::allocator<Segment> >::destroy<Segment>(std::allocator<Segment>&, Segment*) at c:\users\frank\.platformio\packages\toolchain-xtensa-esp32\xtensa-esp32-elf\include\c++\8.4.0\bits/alloc_traits.h:487
(inlined by) std::vector<Segment, std::allocator<Segment> >::_M_erase(__gnu_cxx::__normal_iterator<Segment*, std::vector<Segment, std::allocator<Segment> > >) at c:\users\frank\.platformio\packages\toolchain-xtensa-esp32\xtensa-esp32-elf\include\c++\8.4.0\bits/vector.tcc:165
#7 0x400f9616:0x3ffb2730 in std::vector<Segment, std::allocator<Segment> >::erase(__gnu_cxx::__normal_iterator<Segment const*, std::vector<Segment, std::allocator<Segment> > >) at c:\users\frank\.platformio\packages\toolchain-xtensa-esp32\xtensa-esp32-elf\include\c++\8.4.0\bits/stl_vector.h:1318
(inlined by) WS2812FX::purgeSegments(bool) at wled00/FX_fcn.cpp:1979
#8 0x400fcdaa:0x3ffb2780 in WS2812FX::finalizeInit() at wled00/FX_fcn.cpp:1571
Anything else?
I'm working on a bugfix.
Analysis
My current understanding is:
- user runs a preset with several segments
- global buffer is enabled, so ledsrgb[] points into the global buffer
- when changing LED settings, old segments are purged then re-build - expected
- for the second segment (or any other except for main),
Segment::~Segment()tries free(ledsrgb) - unexpected and this corrupts this heap! - framework error
CORRUPT HEAP: Bad header
Code of Conduct
- I agree to follow this project's Code of Conduct