Possible Stability/Memory issue with bootloader v0.29 and setting v0.29

I have noticed a stability issue after updrading to bootloader v0.29 and settings v0.29.
I am using v2.09.90 firmware

What I observe is a double load of of the default clock.

Here's what I do to provoke the problem.
1) Go into the settings App
2) Change one of the settings, for example set LCD/Wake On/ Twist = On or Off
3) Go Back, Back in the settings app.

I then briefly see a message 'updating boot0'
then 'Reloading'.
Then I see the deafult clock appear to draw, immediately by a second redraw.
So it looks like teh App has been loaded twice. (my just be 2 redraws).

The same does not occur if you just do a BTN3 reset, you only appear to get the App loaded or redrawn
once.

The reason I am reporting this is that prior to updating the bootloader and settings App - my Kitchen Combo app was running fine. But now I can see a repeatable out of memory error being reported. I know that when Kitchen Combo is loaded it uses 80% of memory and it does not allocate further memory. So something has changed.

If I use a BTN3 reset, the Kitchen Combo loads without a low memory error.

Just checked travis build - 2.09.90 is the latest available version to download.

If you can build by your self you would get 2v09.134

I dont build the firmware, I only take the cutting edge when I want a new feature - which was the latest step counter. Had 2v09.90 for about 3 weeks and watch was fine before updating to the latest settings app and bootloader.

Ok, so it doesn't seem to be firmware related.

I can confirm the very same issue here.
Using firmware v2.09, bootloader v0.27 and setting v0.27.

I can confirm this issue, too. But I cannot tell the cause since I updated firmware and apps. But it's running out of memory several times a day.

Ok, thanks...

The apparent double-load is expected. Now, to get app loads a lot faster the Bangle effectively re-writes the bootloader each time settings change - but I'd be pretty sure that the clock doesn't actually end up loaded twice.

I'll look into memory usage before/after though and see if I can find anything concrete - the intention of the latest tweaks was to actually increase speed and reduce memory usage, not to add to it.

Ok, in terms of memory use, as far as I can tell it's not that much different, lets go for something simple - so a complete 'Install default apps', and executing an 'empty' app on 2v09 firmware, and also an app with widgets:

require("Storage").write("empty.js","");
load("empty.js");
process.memory();

require("Storage").write("emptywid.js","Bangle.loadWidgets();Bangle.drawWidgets();");
load("emptywid.js");
process.memory();


// new
={ free: 1983, usage: 117, total: 2100,
// new widgets
={ free: 1891, usage: 209, total: 2100,
// new mclock (long press BTN3)
={ free: 1550, usage: 550, total: 2100
// new mclock after settings
={ free: 1450, usage: 650, total: 2100


// old
={ free: 2002, usage: 98, total: 2100,
// old widgets
={ free: 1902, usage: 200, total: 2100,
// old mclock (even after settings)
={ free: 1570, usage: 530, total: 2100,

I'm not sure if this correlates with what you're seeing, but we're not talking huge extra increases here. Just 20 vars or 1% - and I believe most of that is the added polyfill stuff to add features that will be built in on cutting edge or 2v10 releases.

Rebooting after changing settings though - that's not good. And you're totally right about the double-redraw - it was actually due to the code being executed twice without a reset between. I have now fixed that one though.

I could however be wrong - so if you can reproduce some big memory usage issues please let me know how to reproduce with as minimal steps as possible and I can look into fixing it.

Confirming that changing settings and going back to the clock face no longer causes a redraw after updating to bootloader v0.28!
Thank you, @Gordon !

I could however be wrong - so if you can reproduce some big memory usage issues please let me know how to reproduce with as minimal steps as possible and I can look into fixing it.

Using Gadgetbride + active pedometer + kitchen combo still triggers a low memory error when cycling through the multiple faces (when changing from e-calib to the clock face, specifically).

Hope this further helps.

That's an odd one - just tried here and I'm still seeing ~350 memory blocks free even with Gadgetbridge, Active pedometer and kitchen and cycling through all the screens. It's definitely a bit tight, but I'd have thought there was a little bit of headroom there.

Are you sure it's not got something else installed as well that's eating up the memory?

I have 17 apps installed:

Settings (v0.27)
Default alarm (v0.11)
Vertical Watch face (v0.09)
Torch (v0.02)
Planetarium (v0.03)
Notifications (v0.08)
Heart Rate Monitor (v0.04)
Heart Rate Recorder (v0.05)
Gadgetbridge (v0.22)
Gadgetbridge Music Controls (v0.05)
BangleRun (v0.10)
Active Pedometer (v0.09)
GPS Recorder (v0.22)
Kitchen Combo (v0.12)
Launcher (Default) (v0.06)
RPG dice (v0.02)
Bootloader (v0.28)

Maybe one of these takes up further memory?

Woha. removing "Torch" solved the issue. I was not aware keeping a shortcut in memory would make such a difference!

That's great! Torch itself doesn't look like it'd use loads of RAM, but I guess it might have just been enough to push things over the edge!

If you are getting E-CALIB it means your compass has not been calibrated. I would not expect this to cause any memory issues though. I use ActivePedom as well. I dont use GadgetBridge. When developing Kitchen Combo my experience was that when memory gets to around 90% you start to see LOW_MEM issues. There might be ways that the Kitchen combo code could be optimised better, I'm open to any quick wins that anyone can see. The key issue was that in order to share a common object across watch faces I had to define the object in main app scope and not in the instance of the watch face.

@Stunts - with the setup you show I would expect apps on lines 9,10,12,13,14 and maybe 17 would be active in memory. The rest will be in storage if not being used.

@Gordon - glad you were able to see the double redraw and I was not completely off the mark.

Thanks!
I'll try to take a look at the code, but being a python dev and not usually being very concerned with memory usage, I'm not sure I can be of much help. Still, I'll do my best. _-)