Debian 10中BlueZ bluetoothd（版本5.50）的零星SIGSEGV崩溃是否有错误修复？

我正在为一款商业产品开发软件，该产品运行在Debian 10（Buster）下的Moxa MPC-2070面板计算机（基于Intel Atom）上，支持BlueZ（5.50）蓝牙。该应用程序是使用Qt Creator开发的。我一直在努力寻找一种健壮可靠的方法来扫描蓝牙低能耗设备

由于与Qt中的QBluetoothDiscoveryAgent:：start（）方法相关的一个极端性能问题（我在这里不赘述），我使用bluetoothctl命令来执行BLE设备扫描。bluetoothctl的包装器为其提供输入命令并解析bluetoothctl的输出。偶尔（每1-150次）我启动bluetoothctl来执行BLE扫描时，bluetooth守护进程（bluetoothd）会与SIGSEGV崩溃

以下是Bluetooth崩溃后syslog的尾部：

[315398.536280] show_signal_msg: 8 callbacks suppressed
[315398.536293] bluetoothd[523]: segfault at a8ec8148fd ip 00007f681ba3e143 sp 00007ffc8110a858 error 4 in libdbus-1.so.3.19.11[7f681ba2f000+2e000]
[315398.536343] Code: 85 ed 74 13 0a 18 88 18 48 83 c4 08 5b 5d c3 0f 1f 84 00 00 00 00 00 f7 d3 22 18 88 18 48 83 c4 08 5b 5d c3 0f 1f 00 48 8b 07 <0f> b6 40 02 85 f0 0f 
95 c0 0f b6 c0 c3 55 48 89 fd 53 89 f3 48 83

在我的C包装程序（uveTagScanner）中，fork（）/exec（）运行bluetoothctl并执行输出处理，我能够检测bluetoothd是否崩溃，然后重新启动它。但这只是一个创可贴的解决方案，因为它仍然给我留下了扫描BLE设备不提供所需信息的例子。 关于如何可靠地执行设备扫描，我已经没有什么想法了！我可以尝试使用BlueZ库和Dbus接口API而不是bluetoothctl，但我担心同样的Bluetooth崩溃会发生

#! /bin/bash
COUNT=0
RESULT=0
while [ "${RESULT}" != "9" ]
    do
    COUNT=`expr ${COUNT} + 1`
    echo "Loop #${COUNT}"
    # uveTagScanner -s FEA0 ${@}     # The compiled bluetoothctl wrapper program with output processing
    # RESULT="$?"

    ( echo "menu scan"             # Enter the bluetoothctl scan sub-menu 
    echo "clear"                     # Clear all filter parameters
    echo "transport le"              # Filter scanning for low-energy devices only
    echo "duplicate-data off"        # Disable reporting of duplicate-data
    echo "back"                      # Exit the bluetoothctl scan sub-menu & return to main menu
    echo "scan on"                   # Start scanning for LE devices
    sleep 10                         # Let scanning proceed for 10 seconds
    echo "scan off"                  # Stop scanning for LE devices
    echo "quit"                      # Quit the bluetoothctl command
        ) | bluetoothctl
done