# SOS out of heap (8 flashes) building from cloud **URL:** \ **Category:** Troubleshooting\ **Created:** [June 19, 2014, 9:47pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216 "2014-06-19T21:47:41Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [June 19, 2014, 9:47pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/1 "2014-06-19T21:47:42Z")
I’ve build my code locally and it has been working fine. ``` text data bss dec hex filename 84364 716 12288 97368 17c58 core-firmware.elf ``` When I build from the cloud and flash, the core immediately SOS’s on reset (I don’t even see a white light.) Here’s the stats from the IDE: ``` text data bss dec hex 84736 716 12480 97932 17 In a nutshell: Flash used 85452 / 110592 77.3 % RAM used 13196 / 20480 64.4 % ``` The figures look pretty much the same, yet the cloud compiled sketch fails while the locally compiled one works fine. Any ideas? ---
**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\ **Post date:** [June 20, 2014, 3:29pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/2 "2014-06-20T15:29:45Z")
Hmm, that’s weird. We just released the ram optimization firmware improvements to the build farm yesterday, so it should have at least 4K of ram during startup / handshake, and about 12k of available dynamic ram while connected to the cloud. Any chance you can post your code? Thanks! David ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [June 20, 2014, 3:43pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/3 "2014-06-20T15:43:39Z")
The code is online in a library. To get it, please add the flashee-eeprom library to a app, and copy the integration-test.cpp example to your app. Because of the preprocessor issues I was having, most of the code currently lives in the header integration-tests.h in the library. I’m afraid it’s not trivial code, and I’m not sure how to water it down or even debug it since the sources aren’t local once I’ve built in the cloud. Anything I can do to help, just let me know. ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [June 20, 2014, 6:38pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/4 "2014-06-20T18:38:22Z")
I’ve tried to par it down to a smaller example case: ``` #include "application.h" #include "flashee-eeprom/flashee-eeprom.h" using namespace Flashee; void setup() { Serial.begin(9600); } void loop() { } ``` What’s strange is that the flash library uses dynamic memory allocation and it’s not even invoked. Yet, the Spark flashes red immediately on startup (before wifi connect etc…) The library does have a static initializer - see Devices::userFlash, which allocates an object to manage the user accessible flash region, but it’s only a handful of bytes in size. I have compiled identical code in the IDE and locally and can confirm the local code compiles and runs. ---
**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\ **Post date:** [June 23, 2014, 3:44pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/5 "2014-06-23T15:44:24Z")
Hi @mdma, Cool, yup! Reproduced on my end as well. I’ll dig into this and report back with my findings when I can, it might take me a few days. edit: haven’t dug in yet, but I’m guessing some example file or other file is being wrongly included that maybe uses too much ram. Thanks! David ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [June 29, 2014, 5:16pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/6 "2014-06-29T17:16:33Z")
Hi @dave - any news? @stevespark is also getting the [same problem](https://community.spark.io/t/flashee-eeprom-library-eeprom-storage-in-external-flash/5241). It it’s something I’ve done wrong with the library I’d love to know so I can fix it, but it’s working fine locally. (I should also try the CLI to see if that helps, but I have no time to try that until tomorrow.) ---
**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\ **Post date:** [June 29, 2014, 5:17pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/7 "2014-06-29T17:17:35Z")
I’ll look into this now, I don’t want to block people from using this lib at all, back in a few. Thanks! David ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [June 29, 2014, 5:33pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/8 "2014-06-29T17:33:29Z")
wow, I appreciate that, after all It’s the weekend! you should be taking it easy! ---
**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\ **Post date:** [June 29, 2014, 7:10pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/9 "2014-06-29T19:10:36Z")
Okay, I’ve been looking into this a bit, I haven’t found any obvious issues on the server end, but I did fix a few small bugs. I’m having trouble compiling the library locally: ``` In file included from ../src/flashee-eeprom/flashee-eeprom.h:154:0, from ../src/application.cpp:5: ../src/flashee-eeprom/flashee-eeprom-impl.h: In member function 'virtual bool Flashee::SparkExternalFlashDevice::writePage(const void*, Flashee::flash_addr_t, Flashee::page_size_t)': ../src/flashee-eeprom/flashee-eeprom-impl.h:1309:66: error: invalid conversion from 'const uint8_t* {aka const unsigned char*}' to 'uint8_t* {aka unsigned char*}' [-fpermissive] In file included from ../../core-common-lib/SPARK_Firmware_Driver/inc/hw_config.h:34:0, from ../inc/main.h:37, from ../inc/spark_utilities.h:30, from ../inc/spark_wiring.h:34, from ../inc/application.h:29, from ../src/application.cpp:3: ../../core-common-lib/SPARK_Firmware_Driver/inc/sst25vf_spi.h:65:6: error: initializing argument 1 of 'void sFLASH_WriteBuffer(uint8_t*, uint32_t, uint32_t)' [-fpermissive] ``` ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [June 30, 2014, 4:37pm UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/10 "2014-06-30T16:37:13Z")
Hi @Dave, The compile error is because the library is expecting sFLASH\_Write to take a `const` pointer - I made a pull request to change that in the firmware but it’s not been applied yet. I forgot I had this applied locally. I’ve republished flashee to work with the existing non-const pointer. Only `flashee-eeprom-impl.h` changed - if you copy that to inc/flashee folder it should now compile for you. Alas, I’m still getting the SOS in the online IDE with this change in place. ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [February 7, 2015, 8:26am UTC](https://community.particle.io/t/sos-out-of-heap-8-flashes-building-from-cloud/5216/11 "2015-02-07T08:26:59Z")
Sorry to dig up an old thread, but I think I finally found the cause of this. It’s a result of the order that constructors are called on module-scope static instances. The only guarantee is that constructors within the same module are called in the order of declaration, but constructors that depend on other instances in other modules cannot be sure the other instance has in fact been initialized. > The workaround is to put module static instances in an accessor functions, then when the function is called, the constructor is guaranteed to be executed. I have done this for the static instances in flashee and this fixed the problem. The crazy thing is that the actual initialization order is based on linker order, and that may vary between builds since it’s based on loosely defined aspects such as the order the filesystem returns the list of files in a directory. This is what makes the problem intermittent.