ESP32 Forum

Hi,

I wrote a program (a big/complicated application) that will be continuous running in a forever loop and sometimes response to some udp requests.

I keep having some error message as below before reset:

assertion "is_free(b)" failed: file "/home/user/esp/esp-idf/components/heap/./multi_heap.c", line 305, function: multi_heap_malloc
abort() was called at PC 0x40105c6f on core 0


It will run for an unknown number of reset, before it really run as expected.

Below are files and line number that I get from the backtrace:
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x400870a4
/home/user/esp/esp-idf/components/esp32/./panic.c:546
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x40071a3
??:0
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x400871a3
/home/user/esp/esp-idf/components/esp32/./panic.c:546
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x40105c6f
/Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x40086a0a
/home/user/esp/esp-idf/components/heap/./multi_heap.c:547 (discriminator 1)
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x40082436
/home/user/esp/esp-idf/components/heap/./heap_caps.c:115
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x40082989
/home/user/esp/esp-idf/components/newlib/./syscalls.c:28
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x400d2e50
??:?
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x4011f5ce
??:?
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$ xtensa-esp32-elf-addr2line -e ./build/limidea.elf 0x4011f649
??:?
user@chrysaor-info-ubuntu-14041-desktop-amd64:~/esp/esp-idf/examples/limidea$


Any idea from which part I should start troubleshooting?

If you're saying that the ESP resets several times before your application successfully starts I'd say you have a timing issue in your application causing it to fail during startup. So, start by isolating the issue in a small application, then continue to break it down to find the root cause.

Thanks for the suggestion.
I'm able to isolate the task that causing the reset.
But what kind of timing issue that you're referring to that may cause this reset?

I do the back trace and it pointed me to the tcpip.c under lwip/api, line 474 code as below:

err_t
tcpip_trycallback(struct tcpip_callback_msg* msg)
{
if (!sys_mbox_valid_val(mbox)) {
return ERR_VAL;
}
return sys_mbox_trypost(&mbox, msg);
}

Also, the timers.c under the lwip/core, line 570, which is:

memp_free(MEMP_SYS_TIMEOUT, tmptimeout);

What you're seeing in the traceback is most likely a side effect of the actual problem, which I'm guessing is a either stack overflow, memory overwrite, uninitialized pointers, deallocated memory etc. I say this because the code you're pointing to is part of well tested and used code so it is most likely your code that causes the problem.

Re. the timing issue. If you application is able to start after X attempts, then the logical conclusion is that something depends on something else to be run before during the startup. Do you have dependencies between your tasks? Global pointers? Remember that there are no guarantees that things run in the exact same order each time.

Yes, I agreed that it should be something related to the memory.
Because the backtrace keep relate it back to the memory part of codes.

And yes, I have a global pointer pass in to my tasks.
Maybe I should start from there.

Thanks for your comment!