Memory Leak in origin "iperf" Firmware on factory ESP32-C5-DevKitC-1 (IDFGH-13662)

[ESP32DE]

Memory Leak in "iperf" Firmware on factory ESP32-C5-DevKitC-1

ESP-IDF v5.4-dev-624-g3d167a46ff-dirty 2nd stage bootloader
compile time Jun 20 2024 15:05:08

Description

I have identified a memory leak in the "iperf" firmware running on the ESP32-C5-DevKitC-1. During operation, I observe a continuous increase in memory usage that ultimately leads to a system crash.

( Factory)

Steps to Reproduce

1. Use the ESP32-C5-DevKitC-1, which comes with the factory-installed "iperf" firmware.
2. Connect the kit and access it via PuTTY.
3. Perform repeated Wi-Fi scans and monitor memory usage over time (e.g., using the free command).

(Developer)

Steps to Check your Developer Stuff 5.4 xxxxxxx

1. Flash the latest version of the "iperf" firmware onto the ESP32-C5-DevKitC-1.
2. Start the firmware and conduct a continuous test (e.g., with a high number of connections).
3. Perform repeated Wi-Fi scans and monitor memory usage over time (e.g., using the free command).

Expected Behavior

Memory usage should remain stable or only increase slightly without causing a system crash.

Actual Behavior

Memory usage continuously increases, eventually leading to a system crash.

Additional Information

• Firmware Version: ESP-IDF v5.4-dev-624-g3d167a46ff-dirty

• Operating System:
  I (417) app_init: Project name: iperf
  I (421) app_init: App version: v5.4-dev-624-g3d167a46ff-dirty
  I (427) app_init: Compile time: Jun 20 2024 15:04:46
  I (432) app_init: ELF file SHA256: b16189a7d...
  I (436) app_init: ESP-IDF: v5.4-dev-624-g3d167a46ff-dirty

After starting the "iperf" firmware, I conducted a Wi-Fi scan. At the time of the scan, no Access Point (AP) was present, so none were found. The output of the scan was as follows:

iperf> scan
I (82796) cmd_wifi: sta start to scan
iperf> E (89412) cmd_wifi: No AP found

I then checked the available memory:

iperf> free
169768

This indicates that the available heap memory was at 169768 bytes.

I performed several scans, and I noticed that the used memory was never released. Here are the results of multiple scans:

iperf> scan
I (82796) cmd_wifi: sta start to scan
iperf> E (89412) cmd_wifi: No AP found
iperf> free
169432

iperf> scan
I (184109) cmd_wifi: sta start to scan
iperf> E (190724) cmd_wifi: No AP found
iperf> free
169388

iperf> scan
I (194658) cmd_wifi: sta start to scan
iperf> E (201273) cmd_wifi: No AP found
iperf> free
169352

iperf> scan
I (206392) cmd_wifi: sta start to scan
iperf> E (213008) cmd_wifi: No AP found
iperf> free
169320

iperf> scan
I (218497) cmd_wifi: sta start to scan
iperf> E (225112) cmd_wifi: No AP found
iperf> free
169300

iperf> scan
I (232656) cmd_wifi: sta start to scan
iperf> E (239271) cmd_wifi: No AP found
iperf> free
169248

iperf> scan
I (243204) cmd_wifi: sta start to scan
iperf> E (249819) cmd_wifi: No AP found
iperf> free
169208

As evident from the results, the available memory decreases continuously with each scan, indicating a potential memory leak.

further

Additionally, although Band 2 was already active after start, I selected Band 2 again and checked the memory. The pointers were not released, leading to further memory leaks:

iperf> free
169160

iperf> band 2
W (294275) cmd: (band)new input: 0x2
W (294275) cmd: (band)get band: 0x2

iperf> free
169124

iperf> band 2
W (305295) cmd: (band)new input: 0x2
W (305295) cmd: (band)get band: 0x2

iperf> free
169092

iperf> band 2
W (310602) cmd: (band)new input: 0x2
W (310602) cmd: (band)get band: 0x2

iperf> free
169076

iperf>

( edit : double pasted part removed )

I hope this issue can be investigated. Thank you for your support!

please note also

-> #14521
-> #14021

thank you
best wishes
;-)

@MaxwellAlan

and so on..

further

[ESP32DE]

@MaxwellAlan

#14521 (comment)

[MaxwellAlan]

Hi @ESP32DE

Sorry for reply late.

The C5 sample DevKitC's factory firmware(iperf) was the first bringup version, which aim for customer could be able to experience our latest 5G technology quickly, we are sorry that we did not have time to fully test it, which caused you a bad experience, sorry for this.

Recently, we have some fix for this, please using our IDF master latest commit ffb227e(still waiting for CI sync to Github) and build the iperf example.

Waiting for your response.

Thanks.

[ESP32DE]

Recently, we have some fix for this, please using our IDF master latest commit ffb227e(still waiting for CI sync to Github) and build the iperf example.

Waiting for your response.

thank you @MaxwellAlan for your efforts and service
as soon as possible the sync was done i try to build asap and test it and share the experience
wish you a happy mid-autumn (中秋节) festival in advance if we not read/write next days
best wishes

[jack0c]

@ESP32DE
First and foremost, I apologize on behalf of the Espressif.
There are no reasons to make our customers or developers to “run on each espressif factory problem on a big wall of silent.”
There are no reasons do FW test before released.
There are no reasons to do so many changes without any documents.
We will fix all of issues you face in the progress first, and consider what we can do in the test and documents to solve the problems other developers may be faced.
But I still hope that you can understand in this regard: we have been making developments and adjustments, and there are still some issues with the code.

Again, I apologize for this issue.

[ESP32DE]

@jack0c i am on espressif side, from begin -You won't get rid of me so quickly

• the little bug won't knock you down so quickly :)

Teo did something that no one had ever done before. He turned IoT upside down overnight and it continues to this day. You are a fantastic team, and I am the most impatient person - Teo knows this, espressif knows that, everyone knows that - It is not easy to make everyone and everything fit and fit at the same time. I have a lot of understanding for this, so it was very, very important to me to quickly test the 5G with such a model as the ESP32-C5 and the ESP32-C5-DevKitC with iperf Factory FW and to give feedback as quickly as possible on what I came across before thousands of boards are pre-flamed or come among the people.

I take 138240 "very badly", it took me a long time to figure it out on the boot :) a paper hint would be enough "138240 you need" :)
You see my smiley? - I'm like that. They can't be angry with you, they want you to remain the world's most - stay!

Now all emotional outbursts aside :)

The module, the KIT, RF and all around - excellent! I think the FW appeared too early. The bandwidths are also still missing. Unfortunately, this misleadingly reflects a poor bandwidth - but the C5 is insanely fast. (branding works, traffic works) I think that with the update of the type description it helps quite a bit to show people how damn fast and stable the C5 is. This is a masterpiece from the master! I'll test it as soon as the sync is complete and let you know.

wish you a happy mid-autumn (中秋节) festival in advance if we not read/write next days
greetings fly out to friends all over the globe
best wishes

[jack0c]

@ESP32DE Yes, I understand "i am on espressif side". Thanks for reporting so quickly and keeping following up.
For the baudrate issue, I think the original design is to use 115200 baudrate. I don't know if it is a efuse problem(there is a bit in efuse to show whether use 48MHz or 40MHz XTAL) or just because of the idf of version too old. Our team will give an answer for this soon.

Thanks again.

[jack0c]

@ESP32DE here are some update after discussing with team: the firmware in the module was mainly for internal test, not for the customers or developers.
But I think this the firmware should be useful for customers or developers. We can do some improvement in the sample flow, test and documents.
I suppose we can give customers or developers more options:

1. use the firmware inside the module, with clear document
2. use a recommended esp-idf commit which is relatively stable to build examples and do developing
3. use latest esp-idf master to build examples and do developing

What do you think？

[QingzhaoYin]

@ESP32DE Hi~, for the issue about Memory Leak in "iperf", the reason of increase in memory is the cmd in console will be record to make it easier for users to trace back. In ESP_CONSOLE_REPL_CONFIG_DEFAULT(), the maximum length of the cmd history to be recorded can be modified.

If modify max_history_len to 1, the increase in memory wil not appear.
Moreover, it is recommended to use the "heap" command to check for any memory leaks.

[ESP32DE]

@jack0c

i am ready for testing - but - one bit is different - you see it :) ?
Yes! figured it out :)

@QingzhaoYin
this makes then sense where the memory goes - asap i check all here again.
please understand, i did not had the source code so i could not check much much detailed.
thank you very much for your efforts and service and this hint to the sync -
i switched to the last master for now on VM for ESP32-C5

to do: model infos from sdkconfig.h

[ESP32DE]

@jack0c @QingzhaoYin @MaxwellAlan

this PR should solve the "Unknown" model for ESP32-C5 and ESP32-P4
feel free to change anything on the PR like you want / need . this solves me the "Unknown" model ESP32-C5 also "ESP32-P4"

best wishes

edit: add the newer pr caused the preview does not fit the rules there.