[dev report] Matrix + Long strip -> saving 2D settings or reloading presets reduces free RAM by 50%

[softhack007]

What happened?

Hi @ewoudwijma, @troyhacks, @netmindz,

I have a test setup with an unusual, however perfectly "legal" 2D config - a matrix running several effects in segments, plus a 1x144 strip that does nothing.

when first starting WLED, free ram (after loading the preset) is about 111 Kb.

allocLeds 2112 from 0 allocLeds 96 from 0 Free heap: 119224

after saving 2D settings (no change), WLED gets unstable and slow. Free heap goes down to 60 Kb.

settings resp10 handleSettingsSet(): strip is still drawing effects. strip.waitUntilIdle(): strip idle after 7 ms. (task async_tcp) Matrix ledmap: ( skipped ) resetSegments 1 178x24 allocLeds 12816 from 2112 allocLeds 12816 from 0 allocLeds 12816 from 96 allocLeds 12816 from 0 Free heap: 54356 JSON buffer locked. (11) JSON buffer released. (11) heap_caps_malloc failed to allocate 1536 bytes with Internal Default capabilities - largest free block: 1524; available: 6612 (frag 76.95%). heap_caps_malloc failed to allocate 1622 bytes with 8-Bit_Aligned DMA Internal capabilities - largest free block: 1620; available: 8420 (frag 80.76%).

Observations

I think that the json magick for saving 2D settings does something wrong.

complete LOG files: serial_console.txt

To Reproduce Bug

Code: audio_fastpath branch (should also work on mdev) - just commented out the "slow strip" warning (wlep.cpp). buildenv [env:esp32_16MB_V4_M_debug]

presets and cfg from the zip attached. my_esp32_16M_V4.zip

• start WLED
• open presets tab, re-load preset 12
• goto main UI page (colors)
• open 2D setting, press "save"

--> low memory, slow effects, more problems.

Expected Behavior

The preset load fine at startup. Re-Loading it, or re-saving existing 2D settings should not cause instability.

Install Method

Self-Compiled or other

What version/release of MM WLED?

WLEDMM audio_fastpath (tag 0.14.0-b15.25_neoPixelBus-273)

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[ewoudwijma]

You created a 178x24 = 4272 leds matrix (because of the cjet functionality). Is that intentional? It is very big, bigger then the amount of leds defined (912): are there checks if sPC writes beyond his length ? Did you test what happens on upstream?

[softhack007]

You created a 178x24 = 4272 leds matrix (because of the cjet functionality). Is that intentional?

"Kind of intentional" 😁. Actually I first made the preset for the 32x24 matrix, then added 144 LEDs on another pin. and saved my config with some older release. Then tried to add the new stripe to my existing matrix setup. Yeah that caused a surprise already as all the "nothingness" seems to count as part of the total matrix.

In the log, you can see that there are many segments (and sub-segments) constructed / destructed. And finally, there are four "allocLeds 12816" runs - not sure if so much is really needed. I think the 4x 12816 bytes finally kill my heap.

Did you test what happens on upstream?

My first guess: "crash & reboot"; but joke aside ;-) I'll try this in the next days. In the log there are some "handleSettingsSet(): strip is still drawing effects.", which means that the webserver was waiting for effects to finish. This protection does not exists in upstream, that's why I expect that upstream might just run into dangling pointers and crash. But let's see.

are there checks if sPC writes beyond his length ?

good point, I'll add some debug checks to see if sPC writes beyond buffer limits.

[ewoudwijma]

Got this on made after uploading your cfg and presets, in AP mode as I am on the road. I see that occasionally in AP mode - web sockets in a race...

[softhack007]

Memory fragmentation and several leaks were solved in the meantime. Cannot reproduce this problem any more. Closing.