unexpected reboots : memory problems ?

hi,

i have some problems with some unpredictable reboots when running gipy.

the watch just reboots more or less randomly. there is no error message on the console nor on the watch itself. i'm not sure what is causing this.

i know that adding "jit"; to the display_thick_tile method in the Map class will guarantee an immediate reboot 100% of the time. however if i don't have it there is still a reboot. if i remove the "jit"; in the display_tile method (the jit i currently use) the reboots frequencies decrease but i still have it. if i remove the widgets loading and drawing it decreases even further but i still have it.

my guess is that there is a kind of memory limit i'm reaching but i don't know what.
process.Memory() is not helping me since everything seems ok.
half the memory is free, i still have 48000 of stack.

i'm really not sure what to do here.

I have not seen this with my use of gipy yet. However I noticed that gipy can take the CPU quite a long time busy without interruption. This results in e.g. widgets updating only every minute or so.

Could there be a watchdog kicking in?

no, that's just the cpu the algorithms take to draw the map (and figure where you are if lost).
i'm speaking about the cutting edge version in the git which encounters a bug.

If it's getting a reboot it's likely there is a bug in the JIT interpreter. Which Bangle.js firmware are you on?

If you're able to isolate the code that causes the crash down to something reasonably small then I could take a look and see if I can get it fixed

hi, i'm not too sure.
i'm able to reproduce the crashes deterministically though.

it's not the jit alone because when disabling it completely i also managed to get the bug.

i figured out that this line (758):

            Bangle.setPollInterval(2000); // disable accelerometer as much as we can (a value of 4000 seem to cause hard reboot crashes (segfaults ?) so keep 2000)

seem to cause problems at 4000. just switching to 2000 it seems there are no problems anymore.

however it's not the end of the story because i have two different methods for which i'd like to use the jit. 'display_tiles' and 'display_thick_tiles'.
when i tried on both it always crashed.
when i tried on 'display_tiles' alone it used to work (before my latest changes on powersaving).
but now after the changes when i try on 'display_tiles' alone the behavior is very strange.
it does not crash but the screen flickers, with the streets not being displayed and i get weird messages in the console about incorrect code which does not exist.

i was wondering if i was hitting some limits on memory size.

if you like i can help you reproduce it.

Ahh, ok - yes Bangle.setPollInterval(4000); would do it! It's not a segfault you had, you're just not kicking the watchdog timer enough and so it reboots.

Out of interest why are you setting it so low, or fiddling with it at all? It shouldn't really affect power usage noticeably - with the default value it'll run for over a month if nothing else is sucking the power!

Honestly, I have no idea about what could be causing that issue - maybe try backing out the power saving changes you made until it starts working to see if you can narrow down what's wrong?

hi, so just to let you know, i've been commenting in and out large blocks of code and i finally found the problem. there is a problem in the jit in case of array allocations.

multiple array allocations seem to trigger the bug easily but single array allocation also does it sometimes. putting back the jit i do get a 10% perf increase. that's much less than the initial 50% i got (before optimizing the code manually) but i guess i'll keep it, at least for a bit of testing.

as for the watchdog i just thought i don't really need it anymore so i should just max the interval.
i'll put it back to the standard value. thanks.

Do you think you could come up with a very minimal section of code that exhibits the problem and I can look into a fix?

It's possible that we don't check if it's been possible to allocate an array, and if allocation fails we still try and use it which would cause problems

i gave a try building a small example from scratch but it did not work. so i guess i'll need to start from the full code and trim it. that'll take some time though.