client panics when attempting to discover services on connected server

[fhgalano]

After connecting to a server from a client, attempting to call client.get_service(...) causes the application to panic with

thread '<unnamed>' panicked at /{path-to-cargo-registry}/esp32-nimble-0.10.2/src/client/ble_client.rs:418:28:
null pointer dereference occurred

I can see in the logs of both the client and server that they are reporting a successful connection.

Steps to reproduce:

I have two ESP32C3-Devkit-M-1's - I ran the ble_server example on one and the ble_client example on the other. I also tested running the secure_ble_server / secure_ble_client examples with the same result.

I was also able to produce the same error by setting up a server through the nRf Connect app, and running the ble_client example on an ESP32C3.

[taks]

What version of ESP-IDF are you using?

[fhgalano]

Cargo.toml

[dependencies]
log = "0.4"
esp-idf-svc = { version = "0.51", features = ["critical-section", "embassy-time-driver", "embassy-sync", "alloc"] }
esp32-nimble = { version = "0.10.2", features = ["std"] }
zerocopy = "0.8.14"
zerocopy-derive = "0.8.14"
anyhow = "1.0.95"

[taks]

Could you paste your .cargo/config.toml and sdkconfig.defaults?

[fhgalano]

Sorry for the delay

.cargo/config.toml

[build]
target = "riscv32imc-esp-espidf"

[target.riscv32imc-esp-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor" # Select this runner for espflash v3.x.x
rustflags = [ "--cfg",  "espidf_time64"] # Extending time_t for ESP IDF 5: https://github.com/esp-rs/rust/issues/110

[unstable]
build-std = ["std", "panic_abort"]

[env]
MCU="esp32c3"
# Note: this variable is not used by the pio builder (`cargo build --features pio`)
ESP_IDF_VERSION = "v5.2.2"

# Workaround for https://github.com/esp-rs/esp-idf-template/issues/174
CRATE_CC_NO_DEFAULTS = "1"

sdkconfig.defaults

# Rust often needs a bit of an extra main task stack size compared to C (the default is 3K)
CONFIG_ESP_MAIN_TASK_STACK_SIZE=8000

# Config options for esp32-nimble
CONFIG_BT_ENABLED=y
CONFIG_BT_BLE_ENABLED=y
CONFIG_BT_BLUEDROID_ENABLED=n
CONFIG_BT_NIMBLE_ENABLED=y

[taks]

Thanks.

This error occurs because null checks for pointer dereferences was added in rust 1.86.
(rust-lang/rust#134424)

[FreeMasen]

I am curious if this is potentially also an issue for other null pointers in this project? I am running into a inconsistent issue with characteristic notification events triggering LoadProhibited exceptions which point to this line. I wonder if these dereference and then re-reference should be using something like ptr::as_ref with a guard like

let Some(notify_rx) = event.__bindgen_anon_1.notify_rx.as_ref() else {
    return 0
};

Sorry if this is way off the mark, I can open a separate issue if this is entirely unrelated.

[taks]

@FreeMasen, please open a separate issue.