Commit c7cc causes heap corruption.

[MartinMueller2003]

Board

ESP32 LoLin (real) D32 PRO

Device Description

None. / Nothing

Hardware Configuration

No

Version

other

IDE Name

PlatformIO

Operating System

Windows 10

Flash frequency

80

PSRAM enabled

yes

Upload speed

921600

Description

Code is working with commit: 70b7c3a
Code crashes with commit: c7cc5c9 (next commit to the repo)
Revert to commit: 70b7c3a and crash goes away

FYI: Code crashes on current main. Assuming it is the same issue.

No software changes between tests. Full rebuild between tests.

Sketch

Complete code exhibiting this issue can be found at: https://github.com/MartinMueller2003/ESPixelStick

Debug Message

Backtrace:0x40094bd1:0x3ffbc0c00x400953e6:0x3ffbc0e0 0x40095638:0x3ffbc100 0x400850c2:0x3ffbc120 0x4008513e:0x3ffbc150 0x40084dd9:0x3ffbc1a0 0x4017d18b:0x3ffbc1c0 0x40185ae3:0x3ffbc1e0 0x40182ff5:0x3ffbc200 0x4015404b:0x3ffbc220 
  #0  0x40094bd1:0x3ffbc0c00 in block_locate_free at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_tlsf.c:445
      (inlined by) tlsf_malloc at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_tlsf.c:757

Alternative backtrace
Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.      Backtrace:0x40094865:0x3ffb23f00x40094cfd:0x3ffb2410 0x40094f2a:0x3ffb2430 0x40085105:0x3ffb2450 0x4009530d:0x3ffb2470 0x400d076d:0x3ffb2490 0x400d6963:0x3ffb24b0 0x400ff455:0x3ffb25f0 0x400ffd21:0x3ffb26c0 0x400d067a:0x3ffb27a0 0x4012ecae:0x3ffb2820 
  #0  0x40094865:0x3ffb23f00 in align_ptr at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_tlsf.c:114
      (inlined by) insert_free_block at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_tlsf.c:245
      (inlined by) block_insert at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_tlsf.c:269
      (inlined by) tlsf_free at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/heap/heap_tlsf.c:876

Other Steps to Reproduce

I have added tracing to my code and see that the issue happens in different locations within the code flow. If I add a delay the issue happens earlier in my code. This indicates it is not an operation performed by my code that is causing the crash. I have even gotten the issue to happen when I used a long lived loop in my setup function that feeds WD and outputs a message via the console port.

FYI: Other than outputting strings to the console, this code performs no manipulation of hardware.

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[P-R-O-C-H-Y]

Hi @MartinMueller2003,
Your sketch is using lot of libraries. For faster issue hunt, can you separate for me GPIO functions you are using or the parts of code please? That commit that crashes your code is about changing GPIO functions to use ESP-IDF API. Or if possible, can you test the newest version 2.0.3-RC1 of Arduino-esp32? Thanks

[MartinMueller2003]

I had tested using #master as of 08:00AM ET 3 May 2022 and random versions between the last working and first broken version. I tested a total of 14 broken versions (not fun).

The code in the output section is the only code that manipulates GPIO. The path that crashed most reliably is the one used by the PCA9685 driver (I2C Based) which uses an Arduino lib to manage the device. However, one of my tests was to comment out the PCA driver and I made sure all other GPIO actions in that module were disabled and the code still crashed. Then I added a delay loop before initializing the PCA driver and found that the code crashed in the loop (before it ever got to the PCA driver). This indicates that the issue is something earlier in the code and it just takes a while for the system to destabilize enough to crash. When I investigated further, I was able to see at least two distinct heap corruptions and uses of memory structures by some entity after the heap memory was given to another object. This also caused secondary crashes as my code tried to parse that memory.

[Jason2866]

@MartinMueller2003 There is no general problem in actual Arduino core. We use it for project Tasmota.
Many i2c libs are coded badly (wrong). Without a simple sample test sketch, it is impossible to say Arduino is faulty.

[MartinMueller2003]

I will keep digging to see if I can narrow down which action is causing the issue.

[P-R-O-C-H-Y]

@MartinMueller2003 If you find something more specific, which is causing the issue, let us now so we can take a look.

[MartinMueller2003]

I kept digging and found an issue. I was passing in an invalid GPIO ID to pinMode prior to processing my full configuration. This resulted in triggering the heap corruption and subsequent crash, I suppose it is possible that the lower levels of code are not detecting the invalid GPIO Value and are writing data into ram indiscriminately using the bad GPIO as an index or some such thing. At any rate, making my code behave properly resolves the heap corruption. Thanks for taking the time to look into this and maybe you can convert this into an enhancement request to range check the GPIO values and output an error message when a bad one is encountered.

[P-R-O-C-H-Y]

Thanks for report :) Actually there is in pinMode detection if the pin is valid.

if (!GPIO_IS_VALID_GPIO(pin)) {
      log_e("Invalid pin selected");
return;
}

Can you send me exactly what pin / board you used, so I can retest that in simple sketch, to be sure if in the pinMode the valid pin detection works? Thanks

[MartinMueller2003]

There were two values and I did not dig to see which created the issue. -1 and 35. If I did not send those values, then memory did not get corrupted.

[P-R-O-C-H-Y]

Thanks! Can we close this issue and I will do some tests and open new issue or just make a PR with fix :)

[P-R-O-C-H-Y]

I don't have the same board you have. I use official Espressif boards and for what I see, your board does not have pin 35 available or it might be used for something internal (Analog Input Pins : VP, VN, 32, 33, 34, 35). If you try with -1, you get an error that pin is invalid :) So I think, nothing needs to be fixed.