ESP32 Forum

Hi -

I've got an app that is producing this error message:

assertion "next > (intptr_t)block" failed: file "C:/esp-idf-release-v3.2/components/heap/multi_heap.c", line 124, function: get_next_block
abort() was called at PC 0x400db10f on core 0
0x400db10f: __assert_func at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././new
lib/libc/stdlib/assert.c:63 (discriminator 8)

Followed by a bunch of other stuff.

Does this mean that I'm running out of heap? If so, what are my options?

Thanks...

You can potentially free up memory if you aren't using Bt classic, or memory if you aren't using Bt BLE. Separately or both.

For both...
esp_bt_controller_mem_release(ESP_BT_MODE_BTDM);

https://esp-idf.readthedocs.io/en/lates ... _bt_mode_t

So, do you agree that it seems like I'm running out of memory?

Bluetooth isn't enabled in my make sdkconfig file. Is calling this routine really going to help in this case?

If I do call esp_bt_controller_mem_release(ESP_BT_MODE_BTDM), do I need to call esp_bt_controller_deinit() first?

Thanks...

I made this call: very near the point of the crash; it said I have over 229K remaining. So, I guess this probably isn't a memory shortage after all, unless there's some artificial limit imposed on my program (or one of my tasks).

Any other ideas why this isn't working correctly?

I'm not agreeing it's a memory issue. But if you need to free mem. Could be heap corruption.

My app checks the heap for corruption every 10 minutes.

if ( !heap_caps_check_integrity_all(true) )
{
ledSetAnimation(ANIMATION_SPIN,COLOR(255,0,0,0),0,0);
evtApiSend(EVT_ERR_HEAP_CORRUPT,0);
}

Yeah, I've decided that this problem is almost definitely NOT caused by running out of memory. Thanks for the pointers, fly. I'm going to abandon this topic and start one with a refocused subject.

Actually, this topic still has some life left in it. On a lark, I decided to use the heap test that fly gave me. Got this:

CORRUPT HEAP: Block 0x3a313638 is before prev block 0x3ffd4c48

So...I'm now in an area about which I know very little. Does heap corruption occur because of application-space programming errors, or is this more likely to be some kind of system configuration issue?

Thanks...

Heap corruption typically is caused by invalid pointers or writing to some allocated memory and exceeding the bounds of your allocation. Allocated memory typically has not only the mem you requested but also a block of mem that is used to manage the heap. So just writing one byte past the end of your allocation can corrupt the heap.

John A

Agree this is almost certainly heap corruption.

You can read about heap corruption and some more tools that can be used for debugging it, here:
https://docs.espressif.com/projects/esp ... debug.html

Hi Angus - yeah, I think that's a given. I'll need to learn more about the various tools available for hunting this down, but two things make me wonder:

1. I recently moved to v3.2 of the IDF. I'm not sure I did this entirely correctly. First I tried doing an unzip, but somewhere along the line I got an error message telling me that I had to install via git, so I attempted to do so. It's very possible that I made a mistake using git. Is there some consistency check I can perform to tell me whether my IDF install is OK?

2. I have several tasks running, which communicate through a data structure that contains pointers to each object in the tasks. Each task makes liberal use of routines in other task's primary object. (I can provide an example of this tomorrow.) Am I correct in assuming that all tasks share a common address space? (If not, I don't see how one task could overrun another task's heap.) I think my approach is valid, but I've never done it this way before, so I'm somewhat wary.