Repository navigation
RAM usage and binary size have exploded on AVR in 3.9.17 #1930
Description
With this release, I run out of RAM when trying to drive a single pixel on a Nano. Just #include'ing FastLED without using it burns over 1KiB of RAM. These results are from building with Arduino IDE 1.8.19.
/* RAM used (bytes) to show() 1 LED vs FastLED version
| | (1) #include | (2) CRGB,addLeds<> | (3) CHSV, show() | Global vars (1/2/3)| Flash used (1/2/3)|
|------------------|--------------|--------------------|------------------|--------------------|-------------------|
| (0) No FastLED | 206 | | | 192 | 1908 |
| FastLED 3.9.16 | 223 (+17) | 306 (+83) | 334 (+28) | 209/292/320 | 1946/4314/5234 |
| FastLED 3.9.17 | 1338 (+1134) | ??? crash | ??? crash | 869/952/980 | 6424/8792/9712 |
Activity
nomakewan commentedon May 25, 2025
Have confirmed this on our Mega 2560 project as well.
Compiling with Arduino IDE 1.8.19:
FastLED 3.9.16
Sketch uses 92368 bytes (36%) of program storage space. Maximum is 253952 bytes.
Global variables use 6041 bytes (73%) of dynamic memory, leaving 2151 bytes for local variables. Maximum is 8192 bytes.
FastLED 3.9.17
Sketch uses 96142 bytes (37%) of program storage space. Maximum is 253952 bytes.
Global variables use 6695 bytes (81%) of dynamic memory, leaving 1497 bytes for local variables. Maximum is 8192 bytes.
Low memory available, stability problems may occur.
And with PIO:
FastLED 3.9.16
FastLED 3.9.17
sutaburosu commentedon May 25, 2025
@nomakewan, thanks for confirming the increase in RAM usage and binary size. Did you try flashing the resulting binary to a device, and does it work? I can't get very simple sketches to display anything on just a single LED. As I mentioned in the release announcement on r/fastled, FastLED seems to get trapped in an infinite loop reallocating memory for a HashMap if FastLED.addLeds<> is present in the sketch.
nomakewan commentedon May 26, 2025
Apologies for the delay in responding; I did not originally attempt flashing to the device. I have done so just now and likewise confirm that the device is dead and no LED actions occur. 3.9.17 appears to be a death sentence for AVR.
sutaburosu commentedon May 27, 2025
Thanks to a post on r/FastLED I've just learned that FastLED 3.9.17 only works with an odd number of LEDs. Any even number of LEDs causes it freeze during startup.
If I add
Serial.begin(2000000)then this swaps. Only even numbers of LEDs work, whilst odd numbers fail to start up correctly.This seems to indicate that memory alignment may be involved somehow.
nomakewan commentedon May 27, 2025
Interesting; that does track with my findings. The device in question defaults to two pins, one with 64 LEDs and the other with 62 LEDs.
Notably changing these so that they are odd does not reduce the massive bloat in program size and RAM, so even if it "works" with odd numbers of LEDs there is still clearly something far more fundamental gone wrong.
zackees commentedon May 28, 2025
Is this problem only on nano or also uno?
zackees commentedon May 28, 2025
Looks like a complex static object I used is being constructed unconditionally and not being tree-shooken out. Looks like this is why it's being emitted. I see it in wowki.
I'm going to put the static inside a static function. That will defer initialization and also hopefully causes it to be removed by the linker since a function that is not called is side effect free.
zackees commentedon May 28, 2025
Okay, looks like this might be an issue related to Arduino IDE. PlatformIO is not showing this regression. The whole month the UNO platform has the exact same build size:
nomakewan commentedon May 28, 2025
Nano and Mega 2560 are affected so I must assume Uno is also affected.
Zack, we use PIO exclusively in our project and, as I posted above, you can see that the binary size and especially RAM usage have exploded on our Mega 2560 builds built with PIO. Further, the issue where the AVR is totally dead after flashing the binary compiled with PIO is still there.
This is not an issue with the Arduino IDE.
EDIT: Also the log you posted only goes back to 5/19, and 3.9.17 was released on the 24th. Possible that whatever introduced this behavior was done in those 5 days?
EDIT EDIT: Here is our PIO INI for your reference:
zackees commentedon May 28, 2025
It got truncated because my script aborted whenever one of the builds didn't work, I fixed it and re-ran from the last commit that was good. But otherwise its all the same number.
zackees commentedon May 28, 2025
I submitted a fix already. If you want to run it again and see if it's fixed. I'll begin taking your platformio.ini file and try to reproduce.
nomakewan commentedon May 28, 2025
Tested dfa2b8c against our project using the Arduino IDE. Here were the size results:
This appears to be unchanged from 3.9.17. Is the fix in a separate branch from
main?zackees commentedon May 28, 2025
Can you help me understand why you are compiling a complex project defined by a platformio.ini file through the arduino IDE?
Do you have a parallel process where you install each of these dependencies through the Arduino IDE?
zackees commentedon May 28, 2025
Oops I forgot to check it in, here's the patch:
9696074
nomakewan commentedon May 28, 2025
Nope, just it's easier for me to pick-and-place the FastLED library with the IDE, so I copy the working directory somewhere else, copy the contents of
includesintosrc, and then renamemain.cpptosrc.inoet voila, it opens in the Arduino IDE. I had in fact already done this several days ago so it was already sitting in that working directory ready for me to test with.If you would prefer I learn how to point the platformio.ini file towards a specific commit on a git repo I will, but I figured it was better to go with what I'm familiar with to offer a more immediate answer to your question.
Tested against 9696074 and the result:
This is still larger than 3.9.16 (by 4576 bytes of flash and 7 bytes of RAM) but not incredibly so. Unfortunately the issue where the board never makes it out of
setup()is still present. No serial data comms, nothing. Still dead as a doornail.24 remaining items
nomakewan commentedon May 28, 2025
That commit does solve the odd/even LED issue.
As for the resource use:
For reference, 3.9.16:
It's certainly more than 3.9.16 but nowhere near the massive jump from 3.9.17.
zackees commentedon May 28, 2025
Thanks for your help! I going to merge in this change now and release.
zackees commentedon May 28, 2025
https://www.reddit.com/r/FastLED/comments/1kxalk1/3918_hot_fix_is_out/
sutaburosu commentedon May 28, 2025
Your efforts are greatly appreciated, Zach.
My test sketch gives these results:
The binary size is reduced, but still >3KiB larger than 3.9.16.
Global vars are down to only 13 bytes more than 3.9.16. Runtime RAM usage is now 460 bytes more than 3.9.16, down from 1,115 more in 3.9.17.
The odd/even problem is still present, although it is now reversed. Increasing
CRGB leds[1];to 2 causes the sketch to get stuck at boot.nomakewan commentedon May 28, 2025
Shit, confirmed. I just switched the LED count in my project to an odd number and sure enough, it stops working if I have an odd total now rather than even on 3.9.18. That's on me, when it started working again I should have switched the LED count to make sure that it wasn't just because the problem had flipped to being the opposite issue.
I went back and found the last commit that worked properly in both odd and even configurations. That commit is 8a55629. Here was the resource report of that commit:
The very next commit, commit 595e279, completely breaks once there is an odd number of total LEDs. It also caused a sudden jump in resources which was a telltale of the issue:
Again, my apologies for not switching up the LEDs to make sure the problem hadn't just flipped to the opposite issue.
sutaburosu commentedon May 28, 2025
I just ran
git bisectfrom bc2a1d8 -> HEAD. I built each revision twice with odd/even number of LEDs in the Arduino IDE. I uploaded both the HEXes to Wokwi to see the results. That also landed on 595e279 as the first bad commit.zackees commentedon May 28, 2025
Gcc can't remove unused static global variables for some reason. Good catch!
zackees commentedon May 28, 2025
Round 2
sutaburosu commentedon May 28, 2025
I don't pretend to fully understand the problem, but searching gives the impression that anonymous namespaces are the modern alternative to static globals. Perhaps even the ancient GCC 7.3.0 understands them and might do the right thing in this case?
zackees commentedon May 28, 2025
I think the issue is that modern gcc removes globals if they think no one is linking to them.
If the constructor is meant to invoke the desired side effect, then the result is that the constructor doesn't get run. This is surprising until the first time you experience it and to get around it you add a gcc attribute.
It's not a good compiler feature and i believe it's theoretically wrong. However, I'm sure they get so much code removal because of it that they keep it in anyway and force people to mark the constructors as keep alive.
But the older compiler's i don't think did this, and I think that's what we are having happen now. Older gcc keeps the constructors, new gcc/clang elides them.
The fix is easy, just stick the global as a static variable inside a static function. Static constructors inside a function don't get run until the first call. And if no one links to that function, it can be removed.
zackees commentedon May 28, 2025
Does this commit solve your even odd issue?
https://github.com/FastLED/FastLED#0f9da866a6e096347f3a454d1a375d062fb88acdsutaburosu commentedon May 28, 2025
Yes, yes it does! It also brings down the runtime memory usage to the same as 3.9.16.
The binary size is also basically the same as 3.9.16, with just a couple of extra bytes used when only #include'ing, but gained back when actually using FastLED.
Awesome. Thanks, Zach!