Debugging Stack overflow issue on esp8266

I’m trying to find the cause of a stack overflow, that has come to my attention after upgrading to the latest mongoose os version (2.19.1). It is my understanding that the stack overflow warning system has been improved in recent releases so I assume the issue has always been there but was previously undetected. My issue is that I can’t easily find the point of origin. I tried using the address pointer of the last callback in the warning:

Nov 10 17:05:59.885] esp_main.c:211 Stack overflow! Last cb 0x40267268, ptrs: -1952:0x40262d8d -3128:0x4021cca4 -3536:0x402628f9 -3728:0x40268b48 -3760:0x40238382 -4048:0x4010095f -4064:0x40100285

But when I look it up in the elf file it points me to:

`240 0x40267268 0x000000AB LOCAL | FUNC DEFAULT 0x0005 mgos_mg_poll_cb

Which I believe to be related to the stack overflow warning mechanism itself and not the source of my stack overflow. The stack overflow warning is triggered every minute after a cronjob, but the device does not crash and keeps on running. I tried triggering a core dump directly after the warning but the result was also not very helpful.

Reading symbols from /fw.elf…
Waiting for gdb on 1234
Remote debugging using 127.0.0.1:1234
Found core at 23 - 132347
Mapping DRAM: 98304 @ 0x3ffe8000
Mapping /opt/Espressif/rom/rom.bin at 0x40000000
Mapping /fw.elf .data: 2020 @ 0x3ffe8000
Mapping /fw.elf .rodata: 8 @ 0x3ffe87e4
Mapping /fw.elf .bss: 29136 @ 0x3ffe87f0
Mapping /fw.elf .text: 30632 @ 0x40100000
Mapping /fw.elf .irom0.text: 666831 @ 0x40200010
Loaded core dump from last snippet in /core
0x40106bca in abort () at /mongoose-os/platforms/esp8266/src/esp_exc.c:160
160 /mongoose-os/platforms/esp8266/src/esp_exc.c: No such file or directory.
#0 0x40106bca in abort () at /mongoose-os/platforms/esp8266/src/esp_exc.c:160
#1 0x40267f25 in mgos_task (e=)
at /mongoose-os/platforms/esp8266/src/esp_main.c:222
#2 0x40000f49 in ?? ()
–Type for more, q to quit, c to continue without paging–
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

What would be a logical next step to try to come to the source of the problem, or should I increase the stack size somehow?

Any help is greatly appreciated!

Check you are not using many large auto variables in your functions that may exhaust the stack, and allocate memory from the heap for large variables and buffers.
I’m not into the details on how to configure the stack for the whole Mongoose-OS task, so I can’t help on that department

Thank you for your reply! I’ll try that.