Twinkle effect crashes my ESP32-Wroom-32UE

[MythicalForce]

Log:

assertion "litPixels.end() == find(litPixels.begin(), litPixels.end(), iNew)" failed: file "include/effects/misceffects.h", line 308, function: virtual void TwinkleEffect::Draw()
abort() was called at PC 0x401155d7 on core 1

ELF file SHA256: 0000000000000000

Backtrace: 0x4008a058:0x3ffd21f0 0x4008a2d5:0x3ffd2210 0x401155d7:0x3ffd2230 0x400d5c31:0x3ffd2260 0x40081d45:0x3ffd2320 0x4008b2e6:0x3ffd2390
  #0  0x4008a058:0x3ffd21f0 in invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
  #1  0x4008a2d5:0x3ffd2210 in abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
  #2  0x401155d7:0x3ffd2230 in __assert_func at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)
  #3  0x400d5c31:0x3ffd2260 in TwinkleEffect::Draw() at include/effects/misceffects.h:308 (discriminator 3)
  #4  0x40081d45:0x3ffd2320 in EffectManager::Update() at include/effects/effectmanager.h:323
      (inlined by) DrawLoopTaskEntry(void*) at src/drawing.cpp:230
  #5  0x4008b2e6:0x3ffd2390 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)```

[Steve-git-hub]

I have the same problem; this is what I have found... The assert at line 308 of misceffects.h is complaining that the new allocated index iNew is already in the litPixels deque. This happens because fadeToBlackBy() called in line 322 will (as it says) fade all LED's to Black including those that are flagged as being lit on the litPixels deque. There is no code provided to cull faded-to-black LED's from the deque. Once an LED is set to Black the if statement at line 296 will allow it to be selected as iNew even though it might still be on the litPixels deque... it will then trigger the assert. Thus it is inevitable that sooner or later this assert will be triggered.

The easy solution is to comment out the assert. The code will run happily but every now and then an LED will have a shorter-than-usual twinkle when its "twin" index is popped off the end of the deque and set to black. The better solution would be to use a similar test to the assert in an if statement after line 297 and make the for loop continue to choose a different iNew if the index is already on the deque.

Hope that helps.