BT_LW_WQ stack overflows with debug options

[jtrueb]

The `BT_LW_WQ` stack may overflow with the build with debug options selected.

Without build with debug options selected, the thread analyzer shows nearly all of the stack space used:
[00:00:31.310,882] <inf> thread_analyzer: BT_LW_WQ : STACK: unused 80 usage 1160 / 1240 (93 %); CPU: 0 %


The configuration option for the stack size is not prompted, so it cannot be overridden to fix the issue without editing the NCS SDK.

config BT_LONG_WQ_STACK_SIZE
  # Hidden: Long workqueue stack size. Should be derived from system
  # requirements.
  int
  # should have `prompt "Long workqueue stack size"`
  default 1300 if BT_GATT_CACHING
  default 1140 if BT_TINYCRYPT_ECC
  default 1024

I manually edited /opt/nordic/ncs/v2.1.3/zephyr/subsys/bluetooth/host/Kconfig to allow BT_LONG_WQ_STACK_SIZE to be assigned (to 4096) and I no longer experience the stack overflow with the "Enable debug options" flag.

[00:01:01.317,840] <inf> thread_analyzer:  BT_LW_WQ            : STACK: unused 2776 usage 1256 / 4032 (31 %); CPU: 0 %


[ovrebekk]

Hi 

This is a known issue, and you can follow the existing discussion here:
https://github.com/zephyrproject-rtos/zephyr/issues/52105

I have asked the team for a status update, and I will get back to you once I know more regarding a fix. 

Best regards
Torbjørn

[jtrueb]

I checked https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.1.3/nrf/known_issues.html
It is not a known issue, but I understand your point that it is a known issue.

The proper known issue for this is that the VS Code build configuration with "Enable debug options" or use of alternative optimization settings like CONFIG_NO_OPTIMIZATIONS may cause hard faults due to any stack size usage change from release to release. Faults may be expected behavior for such builds, won't fix. The workaround is to edit the NCS SDK installation manually and assign larger stack sizes as needed.

In the future, zephyr could allow parameterized stack usage to fix this issue but likely will not.

[ovrebekk]

Hi 

Everything is relative I guess

Part of the issue is that the Bluetooth host is not tested in all possible configurations of the project, so you could end up in situations where the stack sizes are not sufficient if you are using a configuration that is not standard.  

I still haven't heard back regarding an update to the issue, but I will let you know when I do. 
We probably won't have anything in the short term though, so if disabling debug options is not possible you will probably have to patch this yourself for now. 

Best regards
Torbjørn

[ovrebekk]

Hi again

No news on an update from our side yet, but one of the developers alerted me to a better workaround than having to alter the SDK files. 

In order to make the BT_LONG_WQ_STACK_SIZE parameter user configurable you can simply add it to your local Kconfig file (just create a file called Kconfig in the project root folder). 

Then you can redefine the parameter with any default value you want:

config BT_LONG_WQ_STACK_SIZE
    int "Long workqueue stack size"
    default 2000
    
source "Kconfig.zephyr"

Best regards
Torbjørn

[jtrueb]

Hi Torbjørn,

Thanks for the workaround option. I will use that for hacks as it is useful in development.

For a non-debug build, the workaround sounds like a bug to me since nothing associates the intended override with the actual SDK version's Kconfig parameter or value.

I am concerned that the workaround adds a manual item to check with each release change that won't be caught at compile time. In my experience, BT_LONG_WQ_STACK_SIZE will probably be renamed to BT_LW_WQ_STACK_SIZE or something and cause stack overflows again on a later release.

 

[ovrebekk]

Hi 

For a non-debug build you shouldn't have to use the workaround at all. 

Any issue with the default configuration should be picked up by our own release testing. 

Best regards
Torbjørn