Reboot due to "Dangerous stack overflow?"



There aren’t so many things that can cause a stack overflow: Either you’re using too much local variables (doesn’t seem to be your case), or your call stack is too deep.
(There is a third possibility which is when you overwrite it with a faulty pointer but because the stack is in a separate space on Pebble I don’t think it’s possible).

I didn’t spot anything in your code, but FWIW last time I got this kind of weird behaviors was when I tried to use math.h (if you call some of the functions a couple of time they will work, but after a few calls I had a crash with a corrupted return address)

You can get the reason of the crash (kind of) if you run the app on your watch from cloudpebble and open the app log; be careful to open it before it crashes, because for some reason the message with the cause of crash used to disappear if you close the app log panel and open it again…).

If that doesn’t help, I would try to trace my functions calls in case there is a recursive error somewhere (but that’s a very long shot)


@LeFauve I tried that - kept CloudPebble connected to the watch constantly (outputting debug message at every tick, so I know it’s still active) and when the reboot happens - log simple stopped with no additional crash message. I do call couple (very simplistic) functions from external files, will try to comment those calls to see if it makes a difference.


Hm. i think I’ve found the reason



The only thing I can think of is that the angle is going negative and accessing memory it shouldn’t. That memory might not actually be important when you are loading smaller bitmaps (ie: you might not have used it), whereas when you load a big bitmap something like a pointer is in the relevant bit of memory (it’s almost always pointers being messed up! :wink: ).

The value of TRIG_MAX_ANGLE is 0xffff, which is only 16 bits, but a negative 32 bit number will be using all 32 bits, so that could be miles away from the actual trig table.


Not quite the end yet… I did that and a few other adjustments, not getting “stack overflow” anymore, but now after a while reboots with this:

I 2016-04-12 11:06:20 reboot_reason.c:147> Dangerously rebooted due to HardFault: LR 0xfffffffd

I 2016-04-12 11:06:20 reboot_reason.c:161> Unread coredump file is present!

Any help in what’s going on is appreciated.


Sounds like something is still overwriting memory, just not causing the same stack issues.

LR (Link Register) is the return address from a function, it usually stores it on the stack, so if something is still overwriting the stack then it’s corrupting the return address (rather than corrupting something that makes it think the stack has overflowed).

Does it still do it if you don’t access any trig functions. Have you tried forcing the angle you pass to the trig functions to be a 16 bit value (“angle & 0xffff” in your trig call would do it).


@allan will play with this today. Still very confused why/how I can overload stack with no deep call stack or such.


The “stack overflow” error is misleading, especially given this latest error. Something is corrupting memory, most likely stack memory.

If you don’t want to post all your code here, I am happy to have a look via email.


@allan sent you a PM, thanks for looking into this!


As a test running layer update on 5ms delay, commented bunch of code already, now crashes with

I 2016-04-12 16:04:07 reboot_reason.c:116> Dangerously rebooted due to Watchdog: Bits 0x81, Mask 0x83
I 2016-04-12 16:04:07 reboot_reason.c:120> Stuck task PC: 0xce06b8, LR: 0x8
I 2016-04-12 16:04:07 reboot_reason.c:124> Stuck callback: 0x804a1c5
I 2016-04-12 16:04:07 reboot_reason.c:161> Unread coredump file is present!

Any idea what this means?


The “Stuck task PC: 0xce06b8, LR: 0x8” shows that the PC (Program Counter) and LR (Link Register) are both bad values, as pointers they should both start 0x80, like the following line.

So, something is still overwriting memory.


You might be able to get some clues by dumping out the built ELF (assuming you are on a local Linux SDK that is!).

/arm-cs-tools/bin/arm-none-eabi-nm -l -S build/chalk/pebble-app.elf | sort > symbols.txt


/arm-cs-tools/bin/arm-none-eabi-objdump -lS build/chalk/pebble-app.elf > dissasembly.txt

They’ll produce lots of text, from what I remember the addresses in the symbols.txt will be the addresses of the functions (and variable) without the 0x80 at the start (I might be wrong with that though, it’s been a while).


I code on CloudPebble, but can bring up my Ubuntu VM with SDK installed. Thanks, will give it a try!


I mean you do use a lot of local variables and constants (I think they land on the stack) and also “? :” which translates to quite large code from my experience (especially when used in function calls). Try to define your repeated GRects at the beginning of the function.
Also the


looks dangerous (but might be ok…)


@“Christian Reinbacher” Thanks for replying. I did make all local variables declaration into global ones as a test and commented out that memory function. Still happens.

Yuriy Galanter said:
@"Christian Reinbacher" Thanks for replying. I did make all local variables declaration into global ones as a test and commented out that memory function. Still happens.
Ok, but I was rather thinking about the lots of same GRects you use in the analog path of your watchface. Those are still local variables (albeit short lived ones)


Oh. Haven’t thought about it… Interesting, thanks! Will play with shufling those around


@“Christian Reinbacher” You’re a Pebble GOD! The GRects where the culprit. I created a global GRect variable and instead of using GRects directly in drawing routines assign them to the variable first and then use the variable. It’s been working since then like a, well, clock.

Please PM me if you want a free license for Future Time watchface. It will be updated with gradient backgrounds soon, now that I got it working with your help.


@“Yuriy Galanter” thanks! Glad that this worked out for you. The result looks really nice and I’m looking forward to my free license :smile:


Nice to hear it’s sorted!