Assertion `!ble_hs_locked_by_cur_task()' failed on Linux Platform
- Dominant language
- C
- Stars
- 893
- Forks
- 512
- Avg merge
- 13d 31m
- Merged PRs (30d)
- 7
Description
When I run NimBLE on linux platform, and enables MYNEWT_VAL_BLE_HS_DEBUG
the error occurs:
nimble/host/src/ble_gap.c: 607: ble_gap_call_event_cb: Assertion `!ble_hs_locked_by_cur_task()' failed.
follow the function ble_hs_lock() --->BLE_HS_DBG_ASSERT(!ble_hs_locked_by_cur_task())--->
ble_hs_locked_by_cur_task() {
#if MYNEWT
struct os_task *owner;
if (!ble_npl_os_started()) {
return ble_hs_dbg_mutex_locked;
}
owner = ble_hs_mutex.mu.mu_owner;
return owner != NULL && owner == os_sched_get_current_task();
#else
return 1;
#endif
when under Linux, the function returns 1 always.
so BLE_HS_DBG_ASSERT(!ble_hs_locked_by_cur_task()) ≈assert(0)
it fails definitely.
Any one come with this question?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at nimble/host/src/ble_gap.c:607 and trace ble_gap_call_event_cb into ble_hs_lock() and ble_hs_locked_by_cur_task(). Reproduce on the Linux platform with MYNEWT_VAL_BLE_HS_DEBUG enabled, then verify that the assertion reflects the actual lock state and no longer fails spuriously.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, linux
- Domain
- embedded-iot, networking, operating-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100