What can I learn from this exception?

[yanshay]

I'm writing some app which is pretty complex.

Suddenly I started getting the following and have no clue how to tell where to look for.
What can I learn from this and what could be the cause?

Exception occurred 'LoadProhibited'
Context
PC=0x422fbb0a       PS=0x00060710
0x422fbb0a - set_chanfreq
    at ??:??
A0=0x822f9210       A1=0x3fce0c20       A2=0x00000985       A3=0x00000000       A4=0x3fcd1cb8
0x3fce0c20 - SpoolEase::____embassy_main_task::{{closure}}::HEAP2
    at ??:??
0x3fcd1cb8 - g_pm
    at ??:??
A5=0x00060300       A6=0x00000100       A7=0x3fcc40c0       A8=0x00000000       A9=0x3fce0c00
0x3fcc40c0 - esp_hal_app_framework::web_server::standalone_captive_redirect_listen_and_serve_task::POOL
    at ??:??
0x3fce0c00 - SpoolEase::____embassy_main_task::{{closure}}::HEAP2
    at ??:??
A10=0x00000985      A11=0x00000100      A12=0x00000001      A13=0x000000ac      A14=0x00000000
A15=0x00000000
SAR=00000015
EXCCAUSE=0x0000001c EXCVADDR=0x0000005c
LBEG=0x400570e8     LEND=0x400570f3     LCOUNT=0x00000000
THREADPTR=0x00000000
SCOMPARE1=0x00000100
BR=0x00000000
ACCLO=0x00000000    ACCHI=0x00000000
M0=0x00000000       M1=0x00000000       M2=0x00000000       M3=0x00000000
F64R_LO=0x3fcce704  F64R_HI=0x00000000  F64S=0x00000004
0x3fcce704 - esp_alloc::HEAP
    at ??:??
FCR=0x00000000      FSR=0x00000000
F0=0x00000000       F1=0x00000000       F2=0x00000000       F3=0x00000000       F4=0x00000000
F5=0x00000000       F6=0x00000000       F7=0x00000000       F8=0x00000000       F9=0x00000000
F10=0x00000000      F11=0x00000000      F12=0x00000000      F13=0x00000000      F14=0x00000000
F15=0x00000000
0x422f4e20
0x422f5136
chm_set_current_channel
    at ??:??
0x422e518e
ieee80211_update_channel
    at ??:??
0x422f7cde
cnx_sta_leave
    at ??:??
0x422f1c28
ieee80211_sta_new_state
    at ??:??
0x422f73eb
mgd_probe_send_timeout_process
    at ??:??
0x422f4adb
0x422f4d02
ieee80211_timer_do_process
    at ??:??
0x4037af3c
ppTask
    at ??:??

[bjoernQ]

You can see it's crashing inside the wifi driver (like the second last function is chm_set_current_channel and you see a few ieee80211_* functions in the backtrace).

To know more details you probably need to look into disassembled/decompiled code at the PC when the crash happens.

The most likely thing is that something got overwritten in memory. Does it crash immediately or after some time of operation or even when doing something special? (like accessing an URL on a web-server running on the device?)

[yanshay]

Thanks

• Is there somewhere an explanation of how to read these exceptions? Because I see there also other functions, and embassy tasks, etc. Whenever it shows I'm pretty clueless.

The code is really complex and has many moving parts working simultaneously, so difficult to tell what really happens. It happened consistently some time after some unrelated user operation made on the application.
Anyway, it eventually disappeared once I reduced the memory for DRAM alloc.

The thing is that prior to this exception I had all kinds of strange communication disconnects, everything worked well except a sudden packet not arriving and then the device couldn't connect to another one while other things worked fine. So I suspected that maybe because I've put some buffers in PSRAM heap maybe that's not working well so moved them to not be in the heap, and that created this exception, which after a lot of trials/errors made me guess it might be related again to stack overriding alloc memory. Once I reduced my RAM heap, the original disconnect disappeared as well.

What I'm trying to say with this long story, is that for me the biggest challenge in developing a complex application with esp-hal is identifying when the stack overruns other memory areas, I guess it's the heap here but not sure. It brings developer back to C++ world of bugs.

If there was some way to check for that, even if not right when it happens, it would be very helpful.

I don't know exactly how memory is structured but if it is stack overriding the RAM heap eventually, maybe it is possible to place some signature right after the alloc section and identify when it is overran whenever alloc is used? So at the beginning of every alloc related function it would test that signature to still be there, and if not it would warn/panic/etc. because once that happens there is no point continuing and that way it's possible to identify it started happening pretty soon after a change that caused it is made even before you see the symptoms that might be much later or not very clear that's the cause.

Maybe it's already available?

[bjoernQ]

Stack growing into heap/data/bss or iram is definitely a real challenge.

On C6 and H2 we have the "flip-link" feature which can help.

For all chips (using a nightly compiler) we support stack-smashing-protection which in our case also doubles as a stack-overflow protection (pretty much working the way you described in the last chapter). To enable that you need the "stack-protector=all" compiler option