Я занимаюсь разработкой программного обеспечения для коммерческого продукта, работающего на панельном компьютере Moxa MP C -2070 (на базе Intel Atom) под Debian 10 (Buster) с поддержкой blueZ (5.50) Bluetooth. Приложение было разработано с использованием Qt Creator. Я изо всех сил пытался найти надежный и надежный метод сканирования устройств Bluetooth с низким энергопотреблением.
Из-за чрезвычайной проблемы с производительностью, связанной с методом QBluetoothDiscoveryAgent :: start () в Qt (чего я не буду go сюда), я использую команду bluetoothctl для выполнения сканирования устройства BLE. Обертка вокруг bluetoothctl предоставляет ему входные команды и анализирует выходные данные из bluetoothctl. Спорадически (один раз каждые 1 - 150 раз), когда я запускаю bluetoothctl для выполнения сканирования BLE, процесс bluetooth-демона (bluetoothd) падает с SIGSEGV.
Вот хвост системного журнала после bluetoothd cra sh :
[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
Я перезапустил bluetoothd с флагом -d, чтобы включить вывод отладки с помощью: $ sudo bluetoothd -d &
И снова запускал сканирование bluetoothctl в al oop, пока bluetoothd снова не вышел из строя. Полный системный журнал, показывающий bluetoothd cra sh, можно найти здесь: Полный системный журнал с bluetoothd SIGSEGV
В приведенном выше системном журнале начальная версия bluetoothd (без -d) cra sh может 14 января 09: 58: 55.
Перезапуск bluetoothd с флагом -d - 14 января 10: 03: 16.
Использование bluetoothctl в цикле начинается с 14 января 10:06:03 .
bluetoothd снова SIGSEGVs в 14 января 10:05:13.
Иногда сбой bluetoothd происходит только после 1 или 2 команд bluetoothctl, а в других случаях требуется много итераций, прежде чем произойдет cra sh.
Этот сценарий оболочки будет воспроизводить cratooth bluetoothd sh. Он выполняет ту же самую функцию, что и моя программа-оболочка C bluetoothctl, но без обработки вывода bluetoothctl. Обратите внимание, что этот скрипт должен запускаться как root или с идентификатором пользователя, который является членом группы «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
В моей программе-оболочке C (uveTagScanner), которая fork () / exe c () s bluetoothctl и выполняет обработку вывода, я могу определить, произошел ли сбой bluetoothd, а затем перезапустить его. Но это всего лишь бинтовое решение, поскольку оно все еще оставляет меня в тех случаях, когда сканирование устройств BLE не дает необходимой информации.
У меня заканчиваются идеи о том, как надежно выполнить устройство BLE. сканирование! Я мог бы попробовать использовать библиотеки BlueZ и API-интерфейсы интерфейса Dbus вместо bluetoothctl, но боюсь, что произойдет тот же самый bluetoothd cra sh.