-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP IDF 5.3.2 assert ble_hs_locked_by_cur_task (IDFGH-14217) #15014
Comments
Hi @danfleck , Can you share more information on how to reproduce this issue ? Are you using any nimble application that is showing this behaviour ? The fix in #13317 is different from the issue mentioned here . Are there any application changes done at your end that reproduces this issue ? Can you possibly share the same with us which will assist us to debug this quicker ? |
Yes. The following is called from main.c:
Then the assert happens in BleHostTask:
|
我也遇到了同样的问题,我猜测问题出现在 ble_gap.c 文件中,ble_gap_rx_rd_rem_sup_feat_complete 函数的修改。 在此函数中,新增了投递事件 但是在ble_gap_call_conn_event_cb -> ble_gap_extract_conn_cb 中也会调用ble_hs_lock(), 导致两次加锁,ble_hs_locked_by_cur_task 触发断言。 |
Please help check if this patch helps when applied to $IDF_PATH/components/bt/host/nimble/nimble branch |
Unfortunately, no. I get the same assert after applying the patch:
09:52:24 assert failed: ble_hs_conn_find ble_hs_conn.c:301 (ble_hs_locked_by_cur_task())
09:52:24 (1)
09:52:24 Backtrace: 0x4037665a:0x3fce3680 0x403841c9:0x3fce36a0 0x4038c6ba:0x3fce36c0 0x420297cb:0x3fce37e0 0x42021398:0x3fce3800 0x4201dc34:0x3fce3860 0x4201d9fb:0x3fce3880 0x4201e115:0x3fce38a0 0x4201d309:0x3fce38c0 0x420c379b:0x3fce38e0 0x403783a9:0x3fce3900 0x4200a099:0x3fce3920 0x40384d19:0x3fce3940
09:52:24 (3)
09:52:24 ELF file SHA256: f78d3fc383f7386e
09:52:24
09:52:24 Entering gdb stub now.
09:52:24 E TRACE 0x4037665a: /Users/REDACTED/esp/v5.3.2/esp-idf/components/esp_system/panic.c:463
09:52:24 E TRACE 0x403841c9: /Users/REDACTED/esp/v5.3.2/esp-idf/components/esp_system/port/esp_system_chip.c:92
09:52:24 E TRACE 0x4038c6ba: /Users/REDACTED/esp/v5.3.2/esp-idf/components/newlib/assert.c:80
09:52:25 E TRACE 0x420297cb: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs_conn.c:301 (discriminator 1)
09:52:25 E TRACE 0x42021398: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_gap.c:2497
09:52:25 E TRACE 0x4201dc34: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs_hci_evt.c:719
09:52:25 E TRACE 0x4201d9fb: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs_hci_evt.c:446
09:52:25 E TRACE 0x4201e115: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs_hci_evt.c:1180
09:52:25 E TRACE 0x4201d309: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs.c:531
09:52:25 E TRACE 0x420c379b: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/porting/npl/freertos/src/npl_os_freertos.c:451
09:52:25 E TRACE 0x403783a9: /Users/REDACTED/esp/v5.3.2/esp-idf/components/bt/host/nimble/nimble/porting/npl/freertos/include/nimble/nimble_npl_os.h:185
09:52:25 E TRACE 0x4200a099: /Users/REDACTED/Documents/Altrix/AED/git/smartaed-firmware/cproc_firmware/main/subsystems/bluetooth/bluetooth.c:663
09:52:25 E TRACE 0x40384d19: /Users/REDACTED/esp/v5.3.2/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:139
From: Rahul ***@***.***>
Date: Tuesday, December 31, 2024 at 10:31 PM
To: espressif/esp-idf ***@***.***>
Cc: Dan F. ***@***.***>, Mention ***@***.***>
Subject: Re: [espressif/esp-idf] ESP IDF 5.3.2 assert ble_hs_locked_by_cur_task (IDFGH-14217) (Issue #15014)
Hi @danfleck<https://github.com/danfleck> , @kaylyun<https://github.com/kaylyun> ,
Please help check if this patch helps when applied to $IDF_PATH/components/bt/host/nimble/nimble branch
ble_hs_locked_cur_task.txt<https://github.com/user-attachments/files/18284363/ble_hs_locked_cur_task.txt>
—
Reply to this email directly, view it on GitHub<#15014 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABEC2NUC52REGMMJSVNV5N32INOS3AVCNFSM6AAAAABTL3CD2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRWHAZDOOJYGE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Hello @danfleck , Ok, so i replaced your application code in the existing nimble examples and ran it and found no issues. Is it possible for you to use existing examples in IDF to check if they work OK or can you share your complete application code that i can use to reproduce the issue. From logs, it looks like an event has been received, while some operations are still in progress ( hence ongoing operation has already taken a lock) . |
@rahult-github same problem if we enable assertion on SDK 5.4, something in the BLE task is not acting correct. BLE Nimble is running in core 0. Just to call the BLE connection from the BLE device and send data the task crashes. If disable assertion works normally. So, there is something wrong with the Nimble code. assert failed: ble_hs_lock ble_hs.c:217 Backtrace: 0x40082418:0x3ffe6150 0x40098ef9:0x3ffe6170 0x4009cf29:0x3ffe6190 0x40135fd9:0x3ffe62c0 0x4013b2ef:0x3ffe62e0 0x4013baeb:0x3ffe6300 0x40136598:0x3ffe6360 0x40136447:0x3ffe6380 0x40136b1b:0x3ffe63a0 0x40135c51:0x3ffe63c0 0x401fe80b:0x3ffe63e0 0x40087ccd:0x3ffe6400 0x400dd3f1:0x3ffe6430 |
I am debugging the currently locked LINE [149] ble_hs_mutex_locked [0] ble_hs_task_handle[0] xTaskGetCurrentTaskHandle[1073620408] So, what seens is okay, for the BLE Scan, Ble change parameters, all runs okay, but when try to iniate the SPP it does act as: LINE [149] ble_hs_mutex_locked [0] ble_hs_task_handle[0] xTaskGetCurrentTaskHandle[1073620408] assert failed: ble_hs_lock ble_hs.c:218 (!ble_hs_locked_by_cur_task()) Backtrace: 0x40082418:0x3ffe6150 0x40098ef9:0x3ffe6170 0x4009cf29:0x3ffe6190 0x40135fec:0x3ffe62c0 0x4013b303:0x3ffe62e0 0x4013baff:0x3ffe6300 0x401365ac:0x3ffe6360 0x4013645b:0x3ffe6380 0x40136b2f:0x3ffe63a0 0x40135c55:0x3ffe63c0 0x401fe81f:0x3ffe63e0 0x40087ccd:0x3ffe6400 0x400dd3f1:0x3ffe6430 |
So, my conclusion is that no matter how its runs the ASSERT is made wrong in the port of NIMBLE to ESP-IDF /**
This doesnt work so far. |
Any update on this topic ? I am using the example of wifi provisioning using BLE and security type 1. assert failed: ble_hs_lock ble_hs.c:216 (!ble_hs_locked_by_cur_task())<\r><\n> |
there is some error on the BLE that causes this behavior, some part of the assert are not correct and cause this invalid. If assert are enable the system will abort because it. If you need assert enable in the firmware, you need to comment the line BLE_HS_DBG_ASSERT(!ble_hs_locked_by_cur_task()); so there will ne no problem at all. |
Answers checklist.
IDF version.
v5.3.2
Espressif SoC revision.
ESP32-S3
Operating System used.
macOS
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
Custom board
Power Supply used.
USB
What is the expected behavior?
I expect it to startup with error.
What is the actual behavior?
Assert: On Nimble BLE init. ble_hs_locked_by_cur_task
Steps to reproduce.
Run the code with nimble init from main.
Debug Logs.
More Information.
This seems like the same issue that was fixed here: Failed assert in BLE NIMBLE during init: ble_hs_locked_by_cur_task (IDFGH-12275) #13317
Did that possibly come back in IDF 5.3.2? Running the same code in IDF 5.3.1 does not assert.
The text was updated successfully, but these errors were encountered: