Examples fail due to lack of memory

[yanshay]

I tried to run the sync_client and async_client examples on ESP32, both had memory issues as below.

I tried to increase the esp_wifi heap size incrementally and tested, it always failed on memory allocation, until it couldn't compile anymore due to too large heap, reporting: section .dram2_uninit' will not fit in region dram2_seg'

Any way to get it to work? And even if I do, does it mean no memory will be left for my app? I don't need much but would need something.

Here are the execution logs:

INFO - esp-wifi configuration Config { rx_queue_size: 5, tx_queue_size: 3, static_rx_buf_num: 10, dynamic_rx_buf_num: 32, static_tx_buf_num: 0, dynamic_tx_buf_num: 32, ampdu_rx_enable: 0, ampdu_tx_enable: 0, amsdu_tx_enable: 0, rx_ba_win: 6, max_burst_size: 1, country_code: "CN", country_code_operating_class: 0, mtu: 1492, heap_size: 95000, tick_rate_hz: 100, listen_interval: 3, beacon_timeout: 6, ap_beacon_timeout: 300, failure_retry_cnt: 1, scan_method: 0 }
Call wifi_connect
Wait to get connected
Wait to get an ip address
Got ip Ok(IpInfo { ip: 192.168.10.96, subnet: Subnet { gateway: 192.168.10.1, mask: Mask(24) }, dns: Some(192.168.10.1), secondary_dns: None })
We are connected!
Making HTTP request
Start tls connect
WARN - Unable to allocate 1044 bytes
WARN - Unable to allocate 1044 bytes



!! A panic occured in 'examples/sync_client.rs', at line 125, column 33:
PanicInfo {
    payload: Any { .. },
    message: Some(
        called `Result::unwrap()` on an `Err` value: MbedTlsError(-9984),
    ),
    location: Location {
        file: "examples/sync_client.rs",
        line: 125,
        col: 33,
    },
    can_unwind: true,
    force_no_backtrace: false,
}

Backtrace:

0x400ee68b
0x400ee68b - core::result::unwrap_failed
    at /Users/my_user/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/result.rs:1679
0x400d69e5
0x400d69e5 - core::result::Result<T,E>::unwrap
    at /Users/my_user/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core/src/result.rs:1102
0x400ec44c
0x400ec44c - Reset
    at /Users/my_user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/xtensa-lx-rt-0.16.0/src/lib.rs:70
0x400ebda1
0x400ebda1 - ESP32Reset
    at /Users/my_user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-hal-0.19.0/src/soc/esp32/mod.rs:114
0x3ffffffd
0x40079a81
0x400806b5
0x400806b5 - log::__private_api::log
    at /Users/my_user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/log-0.4.22/src/__private_api.rs:72
0x40007c31
0x4000073d
0x3ffffffd

[bjoernQ]

While it shows some failed memory allocations the real error is MBEDTLS_ERR_X509_CERT_VERIFY_FAILED = -9984 - did you change the example to connect to a different IP? Otherwise it's most probably due to expired certificates: https://github.com/esp-rs/esp-mbedtls?tab=readme-ov-file#certificates

[yanshay]

Thanks, I used genssl, that still generated an allocation issue, but only 64 bytes, I increased the wifi heap size to 98000 and it worked. I received a 404 page but I guess that's ok.

Also, for the async-client I needed to specify the feature esp-hal-embassy, you may want to consider adding that in the doc (or having it set automatically).

Also in the async version, after returning the response it prints out continuously

WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes
WARN - Unable to allocate 2308 bytes

Seems like it's really tight on memory, does it mean that if I rely on it I will get such memory allocations issues in ESP32 depending on what exactly I'm trying to do? Or once it's working it's going to work well? I prefer not to spend a lot of time just to find out that it works only in demo apps.

Also, the memory that's exhausted is only the dram.seg2, right? (which normally isn't in use by applications). The rest of the RAM is available for my usage?

[bjoernQ]

Those heap allocations depend on what is really happening and not all of that is controlled by your code but depend on the network connection etc. - if memory is already very tight that's for sure not ideal

In the case of ESP32 the WiFi ram and esp-mbedtls RAM is dram-seg2, yes. For other chips it's not separated

[AnthonyGrondin]

Hi, just checking up on this.

Is this still an active issue with the current HEAD of this repository, after all the memory allocation changes?

[ivmarkov]

The examples do work for me on esp32 after #95
(with the exception of mTLS still failing on this and only this chip - but I think the error code designates an MbedTLS timeout!).

... so I'm inclined to close this.