Skip to content
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.

Sign up for GitHub

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

Jump to bottom

esp_bluedroid_init crashes (deep in call stack) (IDFGH-7997) #9507

Closed
2 of 3 tasks
davidzuhn opened this issue Aug 6, 2022 · 7 comments
Closed
2 of 3 tasks

esp_bluedroid_init crashes (deep in call stack) (IDFGH-7997) #9507

davidzuhn opened this issue Aug 6, 2022 · 7 comments
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@davidzuhn
Copy link
Contributor

Environment

  • Development Kit: Adafruit Feather Huzzah-32, ESP32-S3-DevKitC
  • Kit version (for WroverKit/PicoKit/DevKitC): v1.0
  • Module or chip used: ESP32-WROOM-32, ESP32-S3
  • IDF version: v5.0-dev-4723-g30e8f19f5a
  • Build System: CMake
  • Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2022r1-RC1) 11.2.0
  • Operating System: Mac OS
  • Using an IDE?: Bo
  • Power Supply: USB

Problem Description

My program crashes in esp_bluedroid_init in the latest version of esp-idf, but did not as recently as two weeks ago.

In testing my program with esp-idf (v5.0-dev-4379-g36f49f361c) from the master branch, the BLE stack worked just fine. In the latest version of the esp-idf (v5.0-dev-4723-g30e8f19f5a), the program crashes.

I based my code on the examples/bluetooth/bluedroid/ble/gatt_server program. Seeing as that example has not materially changed, I have not modified my program except for changing the different esp-idf versions.

Expected Behavior

esp_bluedroid_init() returns to the calling function

Actual Behavior

The console displays the messages shown below under "Debug Logs" when esp_bluedroid_init is called.

I've checked the values in sdkconfig and there aren't any obvious looking changes from the gatt_server example. I've increased a few stack size settings (to no change):

OLD: CONFIG_BTC_TASK_STACK_SIZE=3072
NEW: CONFIG_BTC_TASK_STACK_SIZE=8192
OLD: CONFIG_BTU_TASK_STACK_SIZE=4096
NEW: CONFIG_BTU_TASK_STACK_SIZE=16384
OLD: CONFIG_DUPLICATE_SCAN_CACHE_SIZE=200
NEW: CONFIG_DUPLICATE_SCAN_CACHE_SIZE=100
OLD: CONFIG_SYSTEM_EVENT_TASK_STACK_SIZE=2304
NEW: CONFIG_SYSTEM_EVENT_TASK_STACK_SIZE=5120
OLD: CONFIG_MAIN_TASK_STACK_SIZE=3584
NEW: CONFIG_MAIN_TASK_STACK_SIZE=5120

Steps to reproduce

  1. run my program, which calls esp_bluedroid_init

Code to reproduce this issue

Unfortunately, I don't have a small test case which reproduces this. The gatt_server example works with either SDK version. I'm still trying to develop a standalone test case.

Debug Logs

Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x40098e9e  PS      : 0x00060633  A0      : 0x800980a9  A1      : 0x3ffe8f10  
0x40098e9e: uxListRemove at /Users/zoo/esp32/esp-idf-latest-20220805/components/freertos/FreeRTOS-Kernel/list.c:200

A2      : 0x3ffe436c  A3      : 0x17b3135a  A4      : 0x17b3135a  A5      : 0x3ffc50a4  
A6      : 0x00060623  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x00000400  
A10     : 0x3ffeb674  A11     : 0x17b3135a  A12     : 0x17b3135a  A13     : 0x00000000  
A14     : 0x17b3135a  A15     : 0x000000a0  SAR     : 0x00000017  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x00000404  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000  


Backtrace: 0x40098e9b:0x3ffe8f10 0x400980a6:0x3ffe8f40 0x4013e6ec:0x3ffe8f70 0x40126071:0x3ffe8fc0 0x40114a60:0x3ffe8ff0 0x40114af6:0x3ffe9020 0x4010f94d:0x3ffe9050 0x4010fadc:0x3ffe9080 0x4013b151:0x3ffe90c0 0x4013e402:0x3ffe90f0 0x40099822:0x3ffe9120
0x40098e9b: uxListRemove at /Users/zoo/esp32/esp-idf-latest-20220805/components/freertos/FreeRTOS-Kernel/list.c:199

0x400980a6: vTaskDelete at /Users/zoo/esp32/esp-idf-latest-20220805/components/freertos/FreeRTOS-Kernel/tasks.c:1348 (discriminator 4)

0x4013e6ec: osi_thread_create at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/common/osi/thread.c:270

0x40126071: BTU_StartUp at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/stack/btu/btu_init.c:187

0x40114a60: bte_main_enable at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/main/bte_main.c:132

0x40114af6: bte_main_boot_entry at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/main/bte_main.c:89

0x4010f94d: btc_init_bluetooth at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/btc/core/btc_main.c:56

0x4010fadc: btc_main_call_handler at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/btc/core/btc_main.c:103

0x4013b151: btc_thread_handler at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/common/btc/core/btc_task.c:204

0x4013e402: osi_thread_run at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/common/osi/thread.c:165 (discriminator 1)

0x40099822: vPortTaskWrapper at /Users/zoo/esp32/esp-idf-latest-20220805/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:151

An extremely similar stack trace can be seen on ESP32-S3:

assert failed: xQueueGenericCreate queue.c:440 (( uxItemSize == 0 ) || ( uxQueueLength == ( xQueueSizeInBytes / uxItemSize ) ))


Backtrace: 0x40376553:0x3fcdbec0 0x40382e91:0x3fcdbef0 0x4038b6ee:0x3fcdbf20 0x403838c5:0x3fcdc040 0x420704bf:0x3fcdc070 0x420706be:0x3fcdc0a0 0x420554c6:0x3fcdc0f0 0x42043d9c:0x3fcdc120 0x42043e32:0x3fcdc150 0x4203eb61:0x3fcdc180 0x4203ecf4:0x3fcdc1b0 0x4206d065:0x3fcdc1f0 0x42070452:0x3fcdc220 0x40387ae6:0x3fcdc250
0x40376553: panic_abort at /Users/zoo/esp32/esp-idf-latest-20220805/components/esp_system/panic.c:412

0x40382e91: esp_system_abort at /Users/zoo/esp32/esp-idf-latest-20220805/components/esp_system/esp_system.c:135

0x4038b6ee: __assert_func at /Users/zoo/esp32/esp-idf-latest-20220805/components/newlib/assert.c:78

0x403838c5: xQueueGenericCreate at /Users/zoo/esp32/esp-idf-latest-20220805/components/freertos/FreeRTOS-Kernel/queue.c:440 (discriminator 2)

0x420704bf: osi_work_queue_create at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/common/osi/thread.c:72

0x420706be: osi_thread_create at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/common/osi/thread.c:231 (discriminator 4)

0x420554c6: BTU_StartUp at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/stack/btu/btu_init.c:187

0x42043d9c: bte_main_enable at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/main/bte_main.c:132

0x42043e32: bte_main_boot_entry at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/main/bte_main.c:89

0x4203eb61: btc_init_bluetooth at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/btc/core/btc_main.c:56

0x4203ecf4: btc_main_call_handler at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/host/bluedroid/btc/core/btc_main.c:103

0x4206d065: btc_thread_handler at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/common/btc/core/btc_task.c:204

0x42070452: osi_thread_run at /Users/zoo/esp32/esp-idf-latest-20220805/components/bt/common/osi/thread.c:165 (discriminator 1)

0x40387ae6: vPortTaskWrapper at /Users/zoo/esp32/esp-idf-latest-20220805/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:151

Other items if possible

  • sdkconfig file (attach the sdkconfig file from your project folder)
  • elf file in the build folder (note this may contain all the code details and symbols of your project.)
  • coredump (This provides stacks of tasks.). Unable to get -- that'll be another report

A binary for the ESP32 is at:

esp_bluedroid_init-bugreport.zip
@espressif-bot espressif-bot added the Status: Opened Issue is new label Aug 6, 2022
@github-actions github-actions bot changed the title esp_bluedroid_init crashes (deep in call stack) esp_bluedroid_init crashes (deep in call stack) (IDFGH-7997) Aug 6, 2022
@aircable
Copy link

The new implementation of BTU_StartUp creates a thread with workqueue length zero:
#define BTU_TASK_WORKQUEUE0_LEN (0)
This causes the osi_thread_create to panic since it requires a workqueue of >0
configASSERT( uxQueueLength > ( UBaseType_t ) 0 );

No idea what the purpose of creating the btu_thread with size zero is.

The idf 4.4 does this:
btu_thread = osi_thread_create(BTU_TASK_NAME, BTU_TASK_STACK_SIZE, BTU_TASK_PRIO, BTU_TASK_PINNED_TO_CORE, 1);

@aircable
Copy link

OK, I was mistaken. In another part the zero size queue get set to default length.

But, the problem is here:
line 186, btu_init.c
change
const size_t workqueue_len[] = {BTU_TASK_WORKQUEUE0_LEN};
to
const size_t workqueue_len[BTU_TASK_WORKQUEUE_NUM] = {BTU_TASK_WORKQUEUE0_LEN, BTU_TASK_WORKQUEUE0_LEN};

For a queue array of 2 initializing only one is an error.

@davidzuhn
Copy link
Contributor Author

That change does get things working again in my app. Thanks a bunch!

@aircable
Copy link

sure, let's hope this thread gets picked up by officials and fixed in the branch quickly.

@esp-cjh
Copy link
Contributor

esp-cjh commented Aug 11, 2022

@aircable Thank you very much. We will fix this ASAP.

espressif-bot pushed a commit that referenced this issue Aug 13, 2022
@wmy-espressif
components/bt: fixed the invalid workqueue number for BTU thread in B…
9aa32bc 
…luedroid

There should be only one workqueue for BTU task. The queue length for the second workqueue of BTU can be uninitialized and caused memory overflow and corruption.

Closes #9507
@davidzuhn
Copy link
Contributor Author

I've applied the patch from the commit referenced, and that also works for me. I hope this makes it into the main & 5.0 branches soon.

@davidzuhn
Copy link
Contributor Author

Confirmed working from the master branch as well. Thanks.

espressif-bot pushed a commit that referenced this issue Aug 19, 2022
@wmy-espressif
components/bt: fixed the invalid workqueue number for BTU thread in B…
73cc09b 
…luedroid

There should be only one workqueue for BTU task. The queue length for the second workqueue of BTU can be uninitialized and caused memory overflow and corruption.

Closes #9507
espressif-bot pushed a commit that referenced this issue Sep 2, 2022
@wmy-espressif
components/bt: fixed the invalid workqueue number for BTU thread in B…
518ace6 
…luedroid

There should be only one workqueue for BTU task. The queue length for the second workqueue of BTU can be uninitialized and caused memory overflow and corruption.

Closes #9507
@espressif-bot espressif-bot added Resolution: Done Issue is done internally Status: Done Issue is done internally and removed Status: Opened Issue is new labels Nov 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@aircable @davidzuhn @espressif-bot @esp-cjh