JUncaught Error: Font bitmap must be a String, in lato.app.jss

I have been trying to catch a hang bug I see very rarely with my Lato clock.
I suspect that the problem is not down to Lato as the clock will run for days without issue
I was trying the mitherm app yesterday and that went offpiste and I had to reset the watch - so it might be associated with that. Prior to installling that app everything had been fine for 10 days or so. Theat could just be clutching at straws as I dont have a reproducable test case for this problem yet - its very random and rare.

Last night I woke up at 5Am and noticed the clock said it was 2:37am - ie the hang had occurred.

This morning I managed to retrieve the log.txt file and can see the following.

The question is, what caused the MEMORY_BUSY ? and did that corrupt the app code ?

 ____                 _ 
|  __|___ ___ ___ _ _|_|___ ___ 
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v16.93 (c) 2021 G.Williams

>
[JInterpreter error: [ 
  "MEMORY_BUSY"
 ]
New interpreter error: MEMORY_BUSY
>
[J-> Bluetooth
<- Terminal
>
[JUncaught Error: Font bitmap must be a String
 at line 3 col 8328 in lato.app.js
...NDg0="),25+(scale<<8)+(1<<16));return­ this;
                                         ^
in function "setFontLatoSmall" called from line 3 col 8784 in lato.app.js
g.reset().setFontLatoSmall();g.setBgColo­r(options.bg).setCol...
                           ^
in function "draw" called from line 9 col 643 in clock_info
options.draw(itm,itm.get(),options);
                                  ^
in function "drawItem" called from line 9 col 2867 in clock_info
drawItem(menu[options.menuA].items[optio­ns.menuB]);
                                                 ^
in function "redraw" called from line 3 col 8602 in lato.app.js
...,h/2);clockInfoMenu.redraw();if(drawT­imeout)clearTimeout(draw...
                               ^
in function "draw" called from line 3 col 8690 in lato.app.js
drawTimeout=undefined;draw();
                           ^
in function called from system
>
[J-> Bluetooth

I wouldn't worry about MEMORY_BUSY, it's just a warning and is unlikely to affect the code.

I think what's been hit is something I noticed with the slopeclock as well.

Basically when you have a custom font, you've got the code in something like setFontLatoSmall which does this.setFontCustom(E.toString(require('h­eatshrink').decompress(atob('...

The issue is that E.toString is used here to create a string from the array, but it has a second effect - it tries to force what is has into a 'flat string' and if it can't it returns 0. Over time the memory can get fragmented and then sometimes it gets so fragmented there's no way to allocate a contiguous memory area of the length needed, and 'E.toString' returns undefined and this breaks.

It's a tricky one to fix nicely, since I can't change E.toString to add an option like {forceFlat:false}as it's supposed to use all it arguments. I could add E.asString or something like that and then we change all the font code to this.setFontCustom((E.asString||E.toStri­ng)(require('heatshrink').decompress(ato­b('...?

I guess the nice solution would be to rename E.toString to E.toFlatString, and to make E.toString just use a string if a flat one can't be allocated - but that would make anyone's code that uses Inline C/assembly unstable unless they changed it.

The way to work around it in your clock is to pre-allocate the font bitmap as was done here: https://github.com/espruino/BangleApps/c­ommit/c47bc078acf593e3e7554c557c1fa01fd6­8fc14a

The side-effect is your clock actually works a bit faster too, at the expense of more RAM usage.