malloc fails with LoadProhibited guru meditation error

[MalteJ]

Hi,

I have a problem with my program:
At a certain point my program stops with a Guru meditation error LoadProhibited.

Code: Select all

I (65449) TLV: free heap: 152908 bytes
I (65449) TLV: tlv->bin: 0x0
I (65449) TLV: tlv->len: 0
I (Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x40083d02  PS      : 0x00060a33  A0      : 0x800d199b  A1      : 0x3ffc12d0  
A2      : 0x0000d554  A3      : 0x00000000  A4      : 0xfb4ca03f  A5      : 0x00000030  
A6      : 0x00000003  A7      : 0x00060023  A8      : 0xfb4ca03f  A9      : 0x4ca03ffb  
A10     : 0x3ffb1364  A11     : 0x00060820  A12     : 0x3ffb7b8c  A13     : 0x00000018  
A14     : 0x400957f2  A15     : 0x3ffb7b84  SAR     : 0x00000014  EXCCAUSE: 0x0000001c  
EXCVADDR: 0xfb4ca043  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x40083d02:0x3ffc12d0 0x400d199b:0x3ffc12f0 0x400d19dc:0x3ffc1310 0x40081982:0x3ffc1330 0x4000bef8:0x3ffc1350 0x400f1956:0x3ffc1370 0x40099d4d:0x3ffc1390 0x400957f5:0x3ffc13f0

When looking with gdb for the backtrace symbols I get the following:

Code: Select all

(gdb) info symbol 0x40083d02
pvPortMallocTagged + 86 in section .iram0.text
(gdb) info symbol 0x400d199b
pvPortMallocCaps + 139 in section .flash.text
(gdb) info symbol 0x400d19dc
pvPortMalloc + 12 in section .flash.text
(gdb) info symbol 0x40081982
_calloc_r + 14 in section .iram0.text
(gdb) info symbol 0x4000bef8
No symbol matches 0x4000bef8.
(gdb) info symbol 0x400f1956
esf_buf_alloc + 486 in section .flash.text
(gdb) info symbol 0x40099d4d
wdevProcessRxSucDataAll + 1665 in section .iram0.text
(gdb) info symbol 0x400957f5
ppTask + 353 in section .iram0.text

The exact backtrace changes with every execution. But it is always something with memory allocation. Sometimes it fails when I try to allocate 34 bytes within my code.
That's why I have logged my free heap space before. I still have about 150k free heap memory.

Now I don't really have an idea what's going on!?!?
Any ideas???

Thank you!

Best,
Malte

[MalteJ]

I have recompiled and now I get

Code: Select all

esp32/esp-idf/components/freertos/./heap_regions.c:368 (vPortFreeTagged)- assert failed!
abort() was called at PC 0x40083de3
Guru Meditation Error: Core  0 panic'ed (abort)

Backtrace: 0x40009203:0x3ffbcef0 0x40084be0:0x3ffbcf10 0x400d145d:0x3ffbcf30 0x40081924:0x3ffbcf50 0x4000beca:0x3ffbcf70 0x400fd75c:0x3ffbcf90 0x4010018b:0x3ffbcfb0

The backtrace shows it is happening in the tcpip_thread:

Code: Select all

(gdb) info symbol 0x4010018b
tcpip_thread + 27 in section .flash.text

What is happening here?

[MalteJ]

I have tested it on another ESP32 and it is the same problem. (pvPortMallocTagged)

[kolban]

What I'd suggest is to see if we can't find the source statement where the error is occurring. Maybe try using the core dump analysis tools ... see:

https://www.youtube.com/watch?v=MpD_3oVJAEs

Since we are working with memory, we may be over-writing memory that you don't own via a malloc or an array. That can cause difficult to diagnose problems. If the problems continue to be non-deterministic, then my experience says that you are stepping on storage you don't own and the background tasks are tripping over it when they want to touch their own memory. You might want to consider posting your app and letting the community eyeball to see if it can be spotted (assuming the app isn't too large). I also suggest a divide an conquer approach. Keep reducing the size and complexity of your app until the most basic functions run and then add them back in one at a time until it breaks.

[MalteJ]

Yeah, I think your feeling is right. Probably I have found the problem. I have had an overflow a few lines before (malloced 32bytes but have written 64bytes to it).

Thank you!!

Malte

[ESP_Sprite]

For other people running into these types of errors: For every malloc you do, the allocator will allocate a bit of memory to return to you. To keep track of memory status, before every allocated and free block it includes a small structure containing amongst others the address of the next free block. Wen you try to allocate a new block of memory, the allocator will use that to iterate amongst all free blocks, to find one to satisfy your request. If, however, you manage to overflow a buffer allocated on the heap somewhere, chances are that you overwrite the little structure that's at the end of it (actually, the one that's at the start of the next block.) When you now try to allocate something again, in the process of finding a chunk of free memory, the allocator will dereference the corrupted address in that block and bam! Guru meditation error.

TL:DR: If you get a guru meditation error in pvPortMallocTagged, check if you haven't earlier overflown a malloc()ed buffer somewhere.