Memory Corruption Problems

manuel2258
Posts: 3
Joined: Fri Feb 14, 2020 3:35 pm

Memory Corruption Problems

Postby manuel2258 » Sun Apr 11, 2021 9:44 am

Hi guys,
I seem to have a few problems regarding memory corruption.
My goal is to write a small and simple async https client for the esp-idf platform. You can view the current version on which this post is based on here:
https://git.sr.ht/~manuel2258/esp-http/ ... 35ebca963b

However since a while I'm constantly getting errors leading to memory corruption, which I have no Idea about how to further debug.
So the main big error that I have is when running the program normally. As the project is a lib the binary is just a simple loop that makes requests to duckduckgo.com. Here I get an StoreProhibited when trying to allocate something.
I (4531) EspRequester: Before request memeory: 138956
I (4541) EspRequester: Connecting to: https://duckduckgo.com/
I (4711) esp-x509-crt-bundle: Certificate validated
I (5941) EspRequester: Wrote 164 bytes
I (6011) EspRequester: After request memeory: 105424
I (6011) EspRequester: Received 7415 bytes
I (6011) BUFFER_POOL: HEAP FREE: 105424
I (6011) BUFFER_POOL: TRYING TO ALLOCATE: 7415
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.

Core 0 register dump:
PC : 0x4002edea PS : 0x00060633 A0 : 0x8002f8ee A1 : 0x3ffd17e0
0x4002edea: remove_free_block at /home/manuel/sdks/esp-idf/components/heap/heap_tlsf.c:213
(inlined by) block_locate_free at /home/manuel/sdks/esp-idf/components/heap/heap_tlsf.c:448
(inlined by) tlsf_malloc at /home/manuel/sdks/esp-idf/components/heap/heap_tlsf.c:757

A2 : 0x3ffd048c A3 : 0x00001cf8 A4 : 0x00060021 A5 : 0x3ffd17c0
A6 : 0x00000000 A7 : 0x00000000 A8 : 0x3ffe6e8c A9 : 0x0000000a
A10 : 0x2d2d213c A11 : 0x0000000a A12 : 0x0a3e2d2d A13 : 0x3f003050
A14 : 0x0000177b A15 : 0x00001cf7 SAR : 0x00000019 EXCCAUSE: 0x0000001d
EXCVADDR: 0x0a3e2d39 LBEG : 0x0a3e2d2d LEND : 0x3f003050 LCOUNT : 0x4002437d
0x4002437d: _xt_user_exc at /home/manuel/sdks/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:627


Backtrace:0x4002ede7:0x3ffd17e0 0x4002f8eb:0x3ffd1800 0x40023779:0x3ffd1820 0x400237ad:0x3ffd1840 0x40030ffd:0x3ffd1860 0x400f6fca:0x3ffd1880 0x400f7451:0x3ffd18a0 0x40087b74:0x3ffd18c0 0x4008960f:0x3ffd1910 0x40087929:0x3ffd1a20 0x40132767:0x3ffd1c60 0x4002d105:0x3ffd1c80
0x4002ede7: remove_free_block at /home/manuel/sdks/esp-idf/components/heap/heap_tlsf.c:212
(inlined by) block_locate_free at /home/manuel/sdks/esp-idf/components/heap/heap_tlsf.c:448
(inlined by) tlsf_malloc at /home/manuel/sdks/esp-idf/components/heap/heap_tlsf.c:757

0x4002f8eb: multi_heap_malloc_impl at /home/manuel/sdks/esp-idf/components/heap/multi_heap.c:197
0x40023779: heap_caps_malloc at /home/manuel/sdks/esp-idf/components/heap/heap_caps.c:145
0x400237ad: heap_caps_malloc_default at /home/manuel/sdks/esp-idf/components/heap/heap_caps.c:177
0x40030ffd: malloc at /home/manuel/sdks/esp-idf/components/newlib/heap.c:31
0x400f6fca: operator new(unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32s2-elf/src/gcc/libstdc++-v3/libsupc++/new_op.cc:50
0x400f7451: operator new[](unsigned int) at /builds/idf/crosstool-NG/.build/xtensa-esp32s2-elf/src/gcc/libstdc++-v3/libsupc++/new_opv.cc:32
0x40087b74: esphttp::BufferPool::BufferAccess::make_copy(unsigned int) at /home/manuel/projects/esp-idf/esp-http/build/../esp-http/src/buffer_pool.cpp:62
0x4008960f: esphttp::EspRequester::make_request(esphttp::IRequest&, esphttp::Response&) at /home/manuel/projects/esp-idf/esp-http/build/../esp-http/src/esp_requester.cpp:89
0x40087929: app_main at /home/manuel/projects/esp-idf/esp-http/build/../esp-http/main.cpp:45
0x40132767: main_task at /home/manuel/sdks/esp-idf/components/freertos/port/port_common.c:134 (discriminator 2)
0x4002d105: vPortTaskWrapper at /home/manuel/sdks/esp-idf/components/freertos/port/xtensa/port.c:168

ELF file SHA256: 2cf8b94cfcc33566

CPU halted.
As the log indicates there is clearly enough heap space left to allocate those few bytes, or could this error mean that the heap is so fragemented that there is not a block left with the needed size?

So I did as the docu indicates and enabled:
CONFIG_HEAP_POISONING_COMPREHENSIVE=y
CONFIG_HEAP_ABORT_WHEN_ALLOCATION_FAILS=y
Which now just immediately failes when the first alloc in the app_main function happens. For example changing the app_main to:
  1. extern "C" void app_main(void) {
  2.   new uint8_t[5];
  3.   return;
  4. }
Will fail with:
I (4�ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe6100,len:0x1704
load:0x4004c000,len:0x9e8
load:0x40050000,len:0x2e48
entry 0x4004c1ec
I (43) boot: ESP-IDF v4.4-dev-744-g1cb31e509 2nd stage bootloader
I (44) boot: compile time 16:15:48
I (44) boot: chip revision: 0
I (47) boot.esp32s2: SPI Speed : 80MHz
I (52) boot.esp32s2: SPI Mode : DIO
I (56) boot.esp32s2: SPI Flash Size : 4MB
I (61) boot: Enabling RNG early entropy source...
I (66) boot: Partition Table:
I (70) boot: ## Label Usage Type ST Offset Length
I (77) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (85) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (92) boot: 2 factory factory app 00 00 00010000 00300000
I (100) boot: End of partition table
I (104) esp_image: segment 0: paddr=00010020 vaddr=3f000020 size=072b4h ( 29364) map
I (119) esp_image: segment 1: paddr=000172dc vaddr=3ffbc750 size=02898h ( 10392) load
I (123) esp_image: segment 2: paddr=00019b7c vaddr=40022000 size=0649ch ( 25756) load
I (136) esp_image: segment 3: paddr=00020020 vaddr=40080020 size=13510h ( 79120) map
I (155) esp_image: segment 4: paddr=00033538 vaddr=4002849c size=042b0h ( 17072) load
I (160) esp_image: segment 5: paddr=000377f0 vaddr=50000000 size=00010h ( 16) load
I (167) boot: Loaded app from partition at offset 0x10000
I (167) boot: Disabling RNG early entropy source...
I (183) cache: Instruction cache : size 8KB, 4Ways, cache line size 32Byte
I (184) cpu_start: Pro cpu up.
I (237) cpu_start: Pro cpu start user code
I (237) cpu_start: cpu freq: 160000000
I (238) cpu_start: Application information:
I (240) cpu_start: Project name: esp-http
I (245) cpu_start: App version: 69f5f90-dirty
I (251) cpu_start: Compile time: Apr 11 2021 11:21:24
I (257) cpu_start: ELF file SHA256: 9d7e04980af857e8...
I (263) cpu_start: ESP-IDF: v4.4-dev-744-g1cb31e509
I (269) heap_init: Initializing. RAM available for dynamic allocation:
I (276) heap_init: At 3FF9E000 len 00002000 (8 KiB): RTCRAM
I (283) heap_init: At 3FFBF7F8 len 0003C808 (242 KiB): DRAM
I (289) heap_init: At 3FFFC000 len 00003A10 (14 KiB): DRAM
I (295) spi_flash: detected chip: generic
I (300) spi_flash: flash io: dio

Memory allocation failed

Backtrace:0x400265db:0x3fffe1d0 0x40026d11:0x3fffe1f0 0x40082cc3:0x3fffe210 0x4002357a:0x3fffe230 0x40023595:0x3fffe250 0x4002b631:0x3fffe270 0x4008729f:0x3fffe290 0x4008122b:0x3fffe2b0 0x400812e9:0x3fffe2d0 0x40023147:0x3fffe310 0x40050e1d:0x3fffe330 0x40051279:0x3fffe370 0x4004c23d:0x3fffe4a0 0x40011371:0x3fffe560 0x4000f788:0x3fffe6f0 0x400072a5:0x3fffe710
0x400265db: panic_abort at /home/manuel/sdks/esp-idf/components/esp_system/panic.c:354
0x40026d11: esp_system_abort at /home/manuel/sdks/esp-idf/components/esp_system/system_api.c:112
0x40082cc3: heap_caps_alloc_failed at /home/manuel/sdks/esp-idf/components/heap/heap_caps.c:67
0x4002357a: heap_caps_malloc at /home/manuel/sdks/esp-idf/components/heap/heap_caps.c:155
0x40023595: heap_caps_malloc_default at /home/manuel/sdks/esp-idf/components/heap/heap_caps.c:177
0x4002b631: malloc at /home/manuel/sdks/esp-idf/components/newlib/heap.c:31
0x4008729f: _GLOBAL__sub_I__ZN9__gnu_cxx9__freeresEv at /builds/idf/crosstool-NG/.build/xtensa-esp32s2-elf/src/gcc/libstdc++-v3/libsupc++/eh_alloc.cc:132
(inlined by) __static_initialization_and_destruction_0 at /builds/idf/crosstool-NG/.build/xtensa-esp32s2-elf/src/gcc/libstdc++-v3/libsupc++/eh_alloc.cc:272
(inlined by) _GLOBAL__sub_I__ZN9__gnu_cxx9__freeresEv at /builds/idf/crosstool-NG/.build/xtensa-esp32s2-elf/src/gcc/libstdc++-v3/libsupc++/eh_alloc.cc:348
0x4008122b: do_global_ctors at /home/manuel/sdks/esp-idf/components/esp_system/startup.c:181 (discriminator 3)
0x400812e9: start_cpu0_default at /home/manuel/sdks/esp-idf/components/esp_system/startup.c:391
0x40023147: call_start_cpu0 at /home/manuel/sdks/esp-idf/components/esp_system/port/cpu_start.c:552

ELF file SHA256: 9d7e04980af857e8

CPU halted.
Which makes me believe there is something wrong with the project config.
I'm running esp-idf version: ESP-IDF v4.4-dev-744-g1cb31e509

And basically just enabled a custom partition so I can fit esp_cert_bundle.h in the binary.
Something perhabs interresting is that I structred the root CMakeLists.txt in a way that I can also use it to build tests which are to be run on the host, however I can't see how that would effect the actual flashed binary.

Also I can build and run examples just fine and I also tried different Hardware, I does neither run the esp32 and esp32-s2 chip.

So what I'm I missing or how could I further debug this?
I have this error now since a very long time and made me quit this project several times ...

I would really appretiate your help and looking forward to your reply!

ccccczh
Posts: 4
Joined: Mon Jul 03, 2023 6:45 am

Re: Memory Corruption Problems

Postby ccccczh » Wed Sep 20, 2023 3:59 am

Hi, it solved? I met the same problem

ESP_adokitkat
Posts: 23
Joined: Thu Jun 22, 2023 12:50 pm

Re: Memory Corruption Problems

Postby ESP_adokitkat » Fri Oct 06, 2023 1:55 pm

ccccczh wrote:
Wed Sep 20, 2023 3:59 am
Hi, it solved? I met the same problem
Hi. Can you please share more info about your issue (used board, IDF version, logs, code which caused it, etc.) or even better create a bug report in ESP-IDF Github repo? Thank you!

Who is online

Users browsing this forum: Bing [Bot] and 124 guests