[Galaxy S 4 i9505 Original Android Development] wpyh:
I must say that I actually used Xposed to get the logs... Yes I know that any bugs reported when Xposed is installed is ignored :p However, this bug seems to affect multiple users, not just Xposed users, so it may not be related to Xposed.

I think the bluetooth problem is one of a hardware glitch / hang / random restart of the bluetooth device. I can say this, because I usually get the error when I have turned on/off my bluetooth headset a few times. It also seems to happen more often when the phone is hot, or when it is busy (for example, when running Waze and making a call).

If we look at the stack: (I removed the timestamps for easier reading)

I/DEBUG ( 225): backtrace:
I/DEBUG ( 225): #00 pc 00000000 <unknown>
I/DEBUG ( 225): #01 pc 00158c11 /system/lib/hw/bluetooth.default.so (vendor_ssrcleanup+16)
I/DEBUG ( 225): #02 pc 0003c1a3 /system/lib/hw/bluetooth.default.so (bte_ssr_cleanup+58)
I/DEBUG ( 225): #03 pc 00127ca5 /system/lib/hw/bluetooth.default.so (btu_hcif_cmd_timeout+548)
I/DEBUG ( 225): #04 pc 00128823 /system/lib/hw/bluetooth.default.so (btu_task+1130)
I/DEBUG ( 225): #05 pc 000d883d /system/lib/hw/bluetooth.default.so
I/DEBUG ( 225): #06 pc 00014f77 /system/lib/libc.so (__pthread_start(void*)+38)
I/DEBUG ( 225): #07 pc 000121eb /system/lib/libc.so (__start_thread+10)

It seems to be like this:

1. Bluetooth device hangs / stops working, so the bluetooth stack calls btu_hcif_cmd_timeout(). The function description is "Handle a command timeout".

2. From the source here: https://github.com/CyanogenMod/andr...ac7a1f6a30ff16fa9fa38507/stack/btu/btu_hcif.c

void btu_hcif_cmd_timeout (UINT8 controller_id)
{

...

num_hci_cmds_timed_out++;
/* When we receive consecutive HCI cmd timeouts for >=BTM_MAX_HCI_CMD_TOUT_BEFORE_RESTART
times, Bluetooth process will be killed and restarted */
if (num_hci_cmds_timed_out >= BTM_MAX_HCI_CMD_TOUT_BEFORE_RESTART)
{
HCI_TRACE_ERROR("Num consecutive HCI Cmd tout =%d Restarting BT process",num_hci_cmds_timed_out);

bte_ssr_cleanup();
usleep(20000); /* 20 milliseconds */
/* Killing the process to force a restart as part of fault tolerance */
kill(getpid(), SIGKILL);
}

...

}

It seems that btu_hcif_cmd_timeout() calls bte_ssr_cleanup() when there have been too many time-outs.

3. The function bte_ssr_cleanup() is defined here: https://github.com/CyanogenMod/andr...62169ac7a1f6a30ff16fa9fa38507/main/bte_main.c

void bte_ssr_cleanup(void)
{
APPL_TRACE_ERROR("%s", __FUNCTION__);
bt_hc_if->ssr_cleanup();
}

The description is a bit scary "sends PWR_OFF to vendor library so that hardware would be turned off as part of hardware subsystem crash". Hardware subsystem crash sounds serious :eek:

4. The above bt_hc_if->ssr_cleanup() points to the function vendor_ssrcleanup(), which calls vendor_interface->ssr_cleanup(). For some reason, as mentioned above, vendor_interface->ssr_cleanup() is NULL, so it crashes.

Maybe vendor_interface->ssr_cleanup() is somehow uninitialized? Or maybe there is some kind of memory corruption that makes it NULL?

---------- Post added 7th October 2015 at 12:10 AM ---------- Previous post was 6th October 2015 at 11:20 PM ----------

Upon further reading, I realized that vendor_interface is initialized in /vendor/lib/libbt-vendor.so, which we have no control over (? yes/no ?).

Maybe the supplied /vendor/lib/libbt-vendor.so didn't properly initialize vendor_interface.