“蓝牙共享已停止工作"执行 LeScan 时 [英] "Bluetooth share has stopped working" when performing LeScan

问题描述

我面前有一堆各种运行 4.3/4.4 的 Android 手机，它们似乎都遇到了蓝牙问题.我正在运行的应用程序只是使用此回调扫描它周围的其他蓝牙设备:http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.LeScanCallback.html

I have a bunch of various Android phones in front of me all running 4.3/4.4 and they all seem to be suffering from some bug in Bluetooth. The app I am running is simply scanning for other bluetooth devices around it using this callback: http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.LeScanCallback.html

只是 LogCating 数据，仍然有问题...

Just LogCatting the data and still having problems...

有没有人知道这个错误并修复它?我真的需要让蓝牙扫描在明天的截止日期前保持稳定，以便我的应用程序演示...

Does anyone know about this bug and have a fix for it? I really need to get bluetooth scanning stable for a deadline I have tomorrow for a demo of my application...

谢谢.

据说在 4.4.3(或 4.4.4)中已解决.(当然，我们为该项目进行演示的那一天……对我们没有好处).主要问题是 XML 文件跟踪 mac 地址增长超过 2000 的大小然后崩溃……系统重置将清除 xml 文件，从而暂时解决问题.

Supposedly in 4.4.3 (or 4.4.4) this was resolved. (Of course the day of our presentation for the project...did us no good). The main issue was the XML file keeping track of mac addresses growing over the size of 2000 and then crashing...a system reset would clear the xml file, thus solving the problem temporarily.

推荐答案

这是 Android 蓝牙代码中的一个 bug，目前似乎没有解决方案.由于其他人也不断发现这一点，因此我将发布我在通过蓝牙堆栈跟踪问题时发现的内容，即使它不能真正用作解决方案，除非有人准备对基于 AOSP 的系统进行重大更改安装.

This is a bug in the Android bluetooth code which does not appear to have a resolution at present. Since other people keep finding this as well, I'm going to post what I found when tracing the problem through the bluetooth stack, even though it cannot really be applied as a resolution unless one is prepared to make major changes to an AOSP-based install.

从根本上说，问题是 btif_config.c 中 find_add_node() 中的 SIGSEGV，当 alloc_node() 在听到太多唯一的 BTLE 硬件地址后失败时.

Fundamentally, the problem is a SIGSEGV in btif_config.c at find_add_node() when alloc_node() fails after hearing too many unique BTLE hardware addresses.

堆栈跟踪的信息部分

D/BtGatt.btif(22509): btif_gattc_upstreams_evt: Event 4096
D/BtGatt.btif(22509): btif_gattc_add_remote_bdaddr device added idx=1
D/BtGatt.btif(22509): btif_gattc_update_properties BLE device name=beacon len=6 dev_type=2
F/libc    (22509): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22530 (BTIF)
I/DEBUG   (  171): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (  171): Build fingerprint: 'google/occam/mako:4.4.2/KOT49H/937116:user/release-keys'
I/DEBUG   (  171): Revision: '11'
I/DEBUG   (  171): pid: 22509, tid: 22530, name: BTIF  >>> com.android.bluetooth <<<
I/DEBUG   (  171): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG   (  171):     r0 ffffffff  r1 00007d00  r2 00007c60  r3 74c7cf00
I/DEBUG   (  171):     r4 74c7cf10  r5 00000000  r6 756f95a8  r7 7503c671

I/DEBUG   (  171): backtrace:
I/DEBUG   (  171):     #00  pc 0004e68c  /system/lib/hw/bluetooth.default.so
I/DEBUG   (  171):     #01  pc 0004ea65  /system/lib/hw/bluetooth.default.so (btif_config_set+156)

反汇编，有问题的代码是这一系列明显有问题的清除 r5 然后尝试将其取消引用为基指针:

Disassembling, the code in question is this rather obviously problematic series of clearing r5 and then attempting to de-reference it as a base pointer:

       4e68a:   2500        movs    r5, #0
       4e68c:   6829        ldr r1, [r5, #0]
       4e68e:   b919        cbnz    r1, 4e698 <btif_gattc_test_command_impl+0x74c>
       4e690:   4630        mov r0, r6
       4e692:   f7dd ef78   blx 2c584 <strdup@plt>

这对应于 find_add_node() 末尾的if(!node->name)"检查

This corresponds to the "if(!node->name)" check at the end of find_add_node()

static cfg_node* find_add_node(cfg_node* p, const char* name)
{
    int i = -1;
    cfg_node* node = NULL;
    if((i = find_inode(p, name)) < 0)
    {
        if(!(node = find_free_node(p)))
        {
            int old_size = alloc_node(p, CFG_GROW_SIZE);
            if(old_size >= 0)
            {
                i = GET_NODE_COUNT(old_size);
                node = &p->child[i];
                ADD_CHILD_COUNT(p, 1);
            } /* else clause to handle failure of alloc_node() is missing here */
        } else ADD_CHILD_COUNT(p, 1);
    }
    else node = &p->child[i];
    if(!node->name)   /* this will SIGSEGV if node is still NULL */
        node->name = strdup(name);
    return node;
}

具体来说，没有 else 子句来处理 alloc_node() 的失败，因此当发生这种情况时(大概是由于听到太多设备地址后存储空间不足)，代码会失败并尝试取消引用名称成员节点指针，但从未将其设置为非空地址.

Specifically, there is no else clause to handle the failure of alloc_node(), so when that happens (presumably due to running out of storage after hearing too many device addresses) the code falls through and attempts to dereference the name member of the node pointer without ever having set it to a non-null address.

修复可能需要涉及:

1. 无法分配新记录时此错误情况的非崩溃处理

1. non-crash handling of this error case when a new record cannot be allocated

当新地址不断被听到并且存储的记录数量变得不合理时，更积极地丢弃过去听到的地址

more aggressive discarding of past-heard addresses when new ones keep being heard and the number of records being stored becomes unreasonable

这篇关于“蓝牙共享已停止工作"执行 LeScan 时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！