ESP32 VERIFY_PTR error gc_free CPU halted

[awesomo4000]

Hi everyone.

I'm using the loboris ESP32 port of micropython, and I get the following error at random times when running my micropython programs. I don't have a tiny test case to reproduce it, and I can't seem to tell why it happens. Has anyone else run into this? How do I fix it or at least easily troubleshoot it?

assertion "VERIFY_PTR(ptr)" failed: file "src/MicroPython_ESP32_psRAM_LoBo/MicroPython_BUILD/components/micropython/py/gc.c", line 594, function: gc_free
abort() was called at PC 0x40114107 on core 1

Backtrace: 0x40092144:0x3ffc33c0 0x400922e7:0x3ffc33e0 0x40114107:0x3ffc3400 0x400e327d:0x3ffc3430 0x400e2af9:0x3ffc3450 0x400ee8f5:0x3ffc3470 0x400ea47d:0x3ffc34a0 0x400ea4e5:0x3ffc34c0 0x400f6f71:0x3ffc34e0 0x400eeb10:0x3ffc3580 0x400eeb61:0x3ffc35a0 0x400eec08:0x3ffc35d0 0x400ea79a:0x3ffc35f0 0x400f4826:0x3ffc3620 0x400ee765:0x3ffc3640 0x400ea47d:0x3ffc3660 0x400f6ee5:0x3ffc3680 0x400ee8bc:0x3ffc3720 0x400ea47d:0x3ffc3750 0x400ea4e5:0x3ffc3770 0x400f6f71:0x3ffc3790 0x400ee8bc:0x3ffc3830 0x400ea47d:0x3ffc38a0 0x400ea4e5:0x3ffc38c0 0x400f6f71:0x3ffc38e0 0x400ee8bc:0x3ffc3980 0x400ea47d:0x3ffc39e0 0x400ea4e5:0x3ffc3a00 0x400f6f71:0x3ffc3a20 0x400ee8bc:0x3ffc3ac0 0x400ea47d:0x3ffc3b20 0x400ea4aa:0x3ffc3b40 0x400dec5e:0x3ffc3b60 0x400deed4:0x3ffc3c10 0x400d5060:0x3ffc3c50

CPU halted.


Thanks

[jickster]

Post the function wherein abort occurred.


Sent from my iPhone using Tapatalk Pro

[awesomo4000]

Thanks for the response. I wish I could identify the micropython function where this occurs, but it happens randomly when my programs are running on the board (Adafruit ESP32HUZZAH). The micropython C code in gc.c is :

https://github.com/loboris/MicroPython_ ... /gc.c#L594

The macro triggering this:

// ptr should be of type void*
#define VERIFY_PTR(ptr) ( \
((uintptr_t)(ptr) & (BYTES_PER_BLOCK - 1)) == 0 /* must be aligned on a block */ \
&& ptr >= (void*)MP_STATE_MEM(gc_pool_start) /* must be above start of pool */ \
&& ptr < (void*)MP_STATE_MEM(gc_pool_end) /* must be below end of pool */ \
)

I haven't broken each of these conditions apart to see which one is causing the abort yet, but thought I would ask if this is a common problem.

[this_andre]

Hi!
I have exactly the same problem as you described. Did you find a solution?
I believe it has to do with memory management.
A solution could be an autorestart of the CPU when this one gets halted. Any idea how to do this?