The Wi-Fi task deletes itself when esp_wifi_deinit() is called, and FreeRTOS
only reclaims its TCB and stack from the idle task afterwards. Test apps that
read the heap right after deinit therefore see that memory as still allocated
and report a leak, most visibly as the eloop unit tests failing on ESP32.
Wait for the idle task at every point where a test deinitialises Wi-Fi
before a leak check, replacing the single-tick delays that only matched what
esp_wifi_deinit() already waits for internally.
pytest.ini enables log_cli, so logging the full ninja stdout after a
failed first-time build is one multi-MB ERROR. That hung shard 3/6 for
hours after the hints test. Log the last 80 lines; keep the full output
on the exception and at DEBUG.
git worktree add materializes submodules as gitlink files. rmtree() cannot
remove those, and exists()+iterdir() on a source gitlink raises and falls
back to shutil.copytree, which leaves mbedtls/include as a file. Unlink
dest gitlinks and only copy populated source directories.
sdkconfig.ci.memprot_esp32s3 was built but listed in no CONFIGS_MEMPROT_*, so
the S3 PMS panic path was never exercised.
expect_gme() takes an optional core, for panics with no attributable core.
On Xtensa the PMS violation shares ETS_MEMACCESS_ERR_INUM with the cache error
and arrives as PANIC_RSN_CACHEERR. ESP32-S2 tells the two apart, ESP32-S3 never
did (//MV note in dd938eb95), so PMS faults were reported as "Cache error".
panic_memprot_fill_info() now claims the panic only when
esp_mprot_get_active_intr() reports a pending violation, and the ESP32-S3 cache
error path consults it, falling back to the cache error report as before.
RISC-V has a dedicated interrupt, so its reporting stays unconditional.
ESP32-S2 and ESP32 are untouched.
Move print_memprot_err_details() and its state out of the RISC-V panic_arch.c
into port/panic_memprot.c behind panic_memprot_fill_info(), so the report can
be shared with the Xtensa PMS targets. No functional change.
change(esp_tee): Force non-deterministic ECDSA signing for TEE secure storage keys
Closes IDF-15937 and IDF-15939
See merge request espressif/esp-idf!50355
Objects with atomic members must not be allocated to PSRAM, otherwise
the ordering guarantee of atomic accesses is weakened due to a hardware
behavior on ESP32 chips. Explicitly request MALLOC_CAP_INTERNAL |
MALLOC_CAP_8BIT for:
- i2c master bus object (atomic status/trans_idx)
- i3c master bus object (atomic fsm)
- ISP processor and AE/AF/AWB/HIST controllers (atomic fsm)
- JPEG decoder/encoder dma2d transaction descriptors (atomic started)
- PPA transaction storage embedding dma2d_trans_t
- dma2d m2m test transaction embedding dma2d_trans_t
Add a bound-checking case for the two cert-extent rejections in
esp_crt_check_bundle(): a certificate whose declared name/key lengths
run past the end of the bundle, and a last certificate placed so close
to the end that its 4-byte header would straddle the bundle boundary.
esp_crt_check_bundle() read the 4-byte certificate header (name_len,
key_len) via esp_crt_get_len() after only checking that the cert's
start offset lies inside the bundle, so a crafted bundle whose first
or last certificate starts within the final 3 bytes caused a transient
out-of-bounds read of up to 3 bytes before the extent check rejected
it. Require the whole header to lie inside the bundle before reading
it.