esp_bluedroid_deinit() crashes [SOLVED]

[cyberman54]

Disabling and deinit bluetooth stack by my application sometimes crashes, in about 1 of 30 cases. Can't find the root cause. Can anyone help?

Using arduino-esp32 v1.0.4 which is based on ESP-IDF v4.1

Relevant Code:
https://github.com/cyberman54/ESP32-Pax ... n.cpp#L281

Error log:

[blecsan.cpp:273] stop_BLEscan(): Shutting down bluetooth scanner ...
blecsan.cpp:276] stop_BLEscan(): unregister GAP callback...
[blecsan.cpp:278] stop_BLEscan(): bluedroid disable...
[blecsan.cpp:280] stop_BLEscan(): bluedroid deinit...

Code: Select all

/home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:1442 (xQueueGenericReceive)- assert failed!
abort() was called at PC 0x40091c41 on core 0
 
#0  0x40095fa0:0x3ffd9750 in invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-components/esp32/panic.c:707
#1  0x400961d1:0x3ffd9770 in abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:707
#2  0x40091c41:0x3ffd9790 in xQueueGenericReceive at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:2520
#3  0x4017128d:0x3ffd97d0 in osi_sem_take at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/osi/semaphore.c:60
#4  0x401b6f8e:0x3ffd97f0 in fixed_queue_enqueue at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/osi/fixed_queue.c:182
#5  0x401b5edd:0x3ffd9810 in transmit_command at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/hci/hci_layer.c:273
#6  0x40185e05:0x3ffd9830 in btu_hcif_send_cmd at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btu/btu_hcif.c:407
#7  0x4018ed45:0x3ffd9850 in btsnd_hcic_ble_update_adv_report_flow_control at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/hcic/hciblecmds.c:1020
#8  0x401da5a1:0x3ffd9870 in hci_update_adv_report_flow_control at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/hci/hci_hal_h4.c:252
#9  0x401da660:0x3ffd9890 in hci_hal_h4_hdl_rx_packet at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/hci/hci_hal_h4.c:319
#10 0x401da698:0x3ffd98b0 in event_uart_has_bytes at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/hci/hci_hal_h4.c:338
#11 0x401b7232:0x3ffd98d0 in fixed_queue_process at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/osi/fixed_queue.c:289
#12 0x401da39d:0x3ffd98f0 in hci_hal_h4_rx_handler at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/hci/hci_hal_h4.c:177
#13 0x40091fad:0x3ffd9920 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)

[cyberman54]

Sometime the crash log looks different, but again shows the issue seems to be caused by the bluetooth stack, pointing to a problem while receiving data from an RTOS queue with xQueueGenericReceive.

Code: Select all

21:43:12.765 >   #0  0x401ac3d2:0x3ffdae90 in bta_dm_observe_results_cb at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/bta/dm/bta_dm_act.c:4234
21:43:12.765 >   #1  0x40189add:0x3ffdafd0 in btm_ble_process_adv_pkt_cont at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btm/btm_ble_gap.c:1869
21:43:12.765 >   #2  0x40189c73:0x3ffdb010 in btm_ble_resolve_random_addr_on_adv at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btm/btm_ble_gap.c:1869
21:43:12.765 >   #3  0x4018c7d3:0x3ffdb040 in btm_ble_resolve_address_cmpl at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btm/btm_ble_addr.c:531
21:43:12.765 >   #4  0x4018c9bd:0x3ffdb060 in btm_ble_match_random_bda at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btm/btm_ble_addr.c:531
21:43:12.765 >   #5  0x4018cbf1:0x3ffdb0a0 in btm_ble_resolve_random_addr at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btm/btm_ble_addr.c:531
21:43:12.765 >   #6  0x40189ba5:0x3ffdb0c0 in btm_ble_process_adv_pkt at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btm/btm_ble_gap.c:1869
21:43:12.765 >   #7  0x4018eb39:0x3ffdb0f0 in btu_ble_process_adv_pkt at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btu/btu_hcif.c:1768
21:43:12.765 >   #8  0x4018f339:0x3ffdb110 in btu_hcif_process_event at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btu/btu_hcif.c:333
21:43:12.765 >   #9  0x4018f43f:0x3ffdb130 in btu_hci_msg_process at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btu/btu_task.c:152
21:43:12.765 >   #10 0x4018f686:0x3ffdb150 in btu_task_thread_handler at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/bt/bluedroid/stack/btu/btu_task.c:229
21:43:12.765 >   #11 0x40091ff1:0x3ffdb180 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)
21:43:12.765 >

[cyberman54]

Addendum: The crash happenes on core0, the app is running on core1. So i guess, this issue maybe a kind of race condition.

[cyberman54]

I found the solution:
esp_ble_gap_stop_scanning() before esp_bluedroid_deinit() avoids this problem.