ESP32 Forum

Posted: **Tue Nov 07, 2017 6:40 am**

I always face Guru Meditation Error of type LoadProhibited occurred on core 1 so I decided to use GDB to trace where is my problem

the tutorial for GDB provided here: viewtopic.php?t=263

finally, I got:
0x400846fb in prvInsertBlockIntoFreeList (pxBlockToInsert=0x3ffcf874)
at /home/abcd/Desktop/backup_fludrive_12_october/esp-idf/components/freertos/./heap_regions.c:420
420 for( pxIterator = &xStart; pxIterator->pxNextFreeBlock < pxBlockToInsert; pxIterator = pxIterator->pxNextFreeBlock )
type" p pxIterator" as the tutorial, it returns $2 = (BlockLink_t *) 0x0, it means that the pointer pxIterator is zero.

may it be a problem of Freertos heap_region in IDF? what should i do next?

Posted: **Tue Nov 07, 2017 7:22 pm**

Hi abcdcadb,

This probably indicates that some code somewhere has corrupted the heap (overwritten a block pointer in the heap with NULL).

If you're able to upgrade to the IDF master branch (pre-V3.0), then we have some new tools for detecting heap corruption as documented here: https://esp-idf.readthedocs.io/en/lates ... debug.html

Unfortunately these features are not in IDF V2.1, however you should be able to follow the general approach there in order to find the code which is corrupting the heap.

Angus

Posted: **Thu Nov 09, 2017 7:59 am**

Thanks for your opinion Angus,

However, the situation is worse, each one i get problem, gdb gives different result. For example, one time I got

Remote debugging using /dev/ttyUSB1
pvPortMallocTagged (xWantedSize=1568, tag=1)
at /home/abcd/Desktop/backup_fludrive_12_october/esp-idf/components/freertos/./heap_regions.c:231
231 while( ( ( pxBlock->xTag != tag ) || ( pxBlock->xBlockSize < xWantedSize ) ) && ( pxBlock->pxNextFreeBlock != NULL ) )
(gdb) p pxBlock
$1 = (BlockLink_t *) 0x14

even the pointer BlockLInk_t was not zero in this case.
I really dont know how my program relates to heap_region of Esp-idf and what is the mean of BlockLInk_t

Posted: **Fri Nov 10, 2017 6:07 am**

I think what Angus is saying is that there is a possibility that you application logic is over-writing memory that doesn't belong to it. For example, I recently came across some code that did the following:

Code: Select all

char tmp;
...
sprintf(&tmp, "Here is my message %s", text);
...

The problem here is that "tmp" is only 1 byte long and sprintf() was writing many more bytes that 1. This wasn't trapped at compile time ... but worse, it didn't show up deterministic ally. It failed with different errors at different times as storage that didn't belong to this function was corrupted. As is always the case, once one finds the problem, it is easy to solve and explains all the symptoms ... and in this case, was relatively easy to find. However this is a simple example and others are much more tricky to find. Perhaps you malloc()'d some storage and have over-run the end of it? Perhaps you allocated an array of 5 structures and are writing to element[5]. Perhaps you malloc'd some storage, freed it and continue to write to the old pointer. There are no shortage of ways that one can corrupt heap and care is needed.

The reference that Angus provided ... https://esp-idf.readthedocs.io/en/lates ... debug.html

Describes a variety of different tools and techniques that have been built into ESP-IDF to attempt to give us (the coders) some assistance in finding these problems ... and ... once found, making coding changes.

What I'd suggest you do is have a good read at the link above. It is medium/advanced stuff. If you have questions on interpreting or understanding what the document is saying, PLEASE post those questions. Only by group discussion can the docs be improved if they aren't sufficiently clear.

Posted: **Thu Nov 16, 2017 3:11 am**

it seems i found out the line which bring error into me. That is a malloc

i called malloc (52) (52 bytes, perhaps)

and GDB return:

Code: Select all

0x4008bc30 in invoke_abort ()
    at /home/abcd/Desktop/PSRAM/esp-idf/components/esp32/./panic.c:139
139	        *((int *) 0) = 0;
(gdb) bt
#0  0x4008bc30 in invoke_abort ()
    at /home/abcd/Desktop/PSRAM/esp-idf/components/esp32/./panic.c:139
#1  0x4008bd26 in abort ()
    at /home/abcd/Desktop/PSRAM/esp-idf/components/esp32/./panic.c:148
#2  0x4008b3c6 in multi_heap_assert (address=<optimized out>, line=370, 
    format=0x3ffb3a84 "CORRUPT HEAP: multi_heap.c:%d detected at 0x%08x\n", 
    condition=<optimized out>)
    at /home/abcd/Desktop/PSRAM/esp-idf/components/heap/./multi_heap_platform.h:55
#3  multi_heap_malloc_impl (heap=0x3ffbcfe8, size=52)
    at /home/abcd/Desktop/PSRAM/esp-idf/components/heap/./multi_heap.c:370
#4  0x40084f2f in heap_caps_malloc (size=52, caps=6144)
    at /home/abcd/Desktop/PSRAM/esp-idf/components/heap/./heap_caps.c:116
#5  0x40084f70 in heap_caps_malloc_default (size=52)
    at /home/abcd/Desktop/PSRAM/esp-idf/components/heap/./heap_caps.c:149
#6  0x40085507 in trace_malloc (size=52, caps=0, mode=TRACE_MALLOC_DEFAULT)
    at /home/abcd/Desktop/PSRAM/esp-idf/components/heap/./heap_trace.c:324
#7  0x40085704 in __wrap_malloc (size=52)
    at /home/abcd/Desktop/PSRAM/esp-idf/components/heap/./heap_trace.c:392

as the tutorial you gave me, I enable heap debug with "basic mode" and put "heap_caps_check_integrity" before I call malloc and got:

Code: Select all

block 0x3ffd8200 is before prev block 0x3ffd8244

I also check my free heap(by heap_caps_get_free_size) at the same time and i recognize that it is much (4264156)

any idea?

Posted: **Thu Nov 16, 2017 5:37 am**

abcdcadb wrote:any idea?

Try adding more calls to heap_caps_check_integrity() at different times in your code, and narrow down a window of time when the corruption occurs. Then look for code in that window which is overflowing a buffer or writing to memory which it shouldn't be writing to.

Posted: **Mon Nov 20, 2017 12:42 pm**

here is where I guess the problem came:

Code: Select all

iLen=strlen(pName);  // pName is parameter of function, type is const char*
cName    = (char*)heap_caps_malloc(iLen,MALLOC_CAP_SPIRAM); // cName type is char*
if(!heap_caps_check_integrity_all(true)) printf("\nfhandle 6");
	printf("\n pname %s",pName);	
printf("\n free is %d",heap_caps_get_free_size(MALLOC_CAP_SPIRAM));
strcpy(cName,pName);
printf("\n free2 is %d",heap_caps_get_free_size(MALLOC_CAP_SPIRAM));

if(!heap_caps_check_integrity_all(true)) printf("\nfhandle 7 ");

it shows:

Code: Select all

free is 4144988                                                                
CORRUPT HEAP: Block 0xaaa55568 is outside heap (last valid block 0x3fbfff00)    
 free2 is 4144988                                                               
CORRUPT HEAP: Block 0xaaa55568 is outside heap (last valid block 0x3fbfff00)    
fhandle 7

it means that the line: "strcpy(cName,pName)"causes corrupt heap, but it seems the free heap is too much to be overflowed

Any idea to fix?

Posted: **Mon Nov 20, 2017 1:06 pm**

Yes, the error is pretty obvious. C strings consist of a number of characters terminated by a 0-character. Strlen gives the amount of 'real' characters in the string, excluding the 0-character. You then use that count to allocate new memory. However, strcpy copies the string and terminates it with a final 0-character, but you have not allocated space for that 0-character. It overwrites some stuff that is part of the heap internals and you get a crash.

ESP32 Forum

is here a problem of heap_region in freertos library in IDF?

is here a problem of heap_region in freertos library in IDF?

Re: is here a problem of heap_region in freertos library in IDF?

Re: is here a problem of heap_region in freertos library in IDF?

Re: is here a problem of heap_region in freertos library in IDF?

Re: is here a problem of heap_region in freertos library in IDF?

Re: is here a problem of heap_region in freertos library in IDF?

Re: is here a problem of heap_region in freertos library in IDF?

Re: is here a problem of heap_region in freertos library in IDF?