Closed Bug 791413 Opened 9 years ago Closed 9 years ago

Attempting to pair Otoro to a macbookair will crash immediately


(Core :: DOM: Device Interfaces, defect)

Gonk (Firefox OS)
Not set



blocking-basecamp +


(Reporter: tchung, Assigned: qdot)



(Keywords: crash)


(2 files)

When trying to pair Otoro to a MacbookAir, the device will immediately crash and self restart itself.

Logcat attached.

- mac book air, OSX 10.7.4, bluetooth pairing on.
- otoro daily build, 9-14-2012
  <project name="fake-dalvik" path="dalvik" remote="b2g" revision="ca1f327d5acc198bb4be62fa51db2c039032c9ce"/>
  <project name="gaia" path="gaia" remote="b2g" revision="38a8a00edc927039a64534dfd98ef180107c7749"/>
  <project name="releases-mozilla-central" path="gecko" remote="mozilla" revision="c135e35cffe8b2a4cddd478cb642631e3d586dc0"/>
  <project name="gonk-misc" path="gonk-misc" remote="b2g" revision="8f338e693745722f53566e5bde639179d1fbcdd4"/>
  <project name="rilproxy" path="rilproxy" remote="b2g" revision="32106d4ea635ebe17a1610b643b398db639b8b97"/>

1) launch settings > bluetooth
2) turn on bluetooth
3) check that it finds your MBA
4) click the device on the phone to pair
5) Verify the phone quickly crashes, and gets stuck in this rebooting loop.  It never recovers back to the homescreen.

09-15 00:48:49.277: I/qcom-bluetooth(618): /system/etc/ Bluetooth QSoC firmware download succeeded, /dev/ttyHS0 qualcomm-ibs 3000000 84:74:2a:eb:f3:3c 
09-15 00:48:49.287: I/qcom-bluetooth(619): /system/etc/ start hciattach 
09-15 00:48:49.307: I/qcom-bluetooth(621): /system/etc/ start_hciattach: pid = 620 
09-15 00:48:49.397: I/GonkDBus(105): DBus Thread Starting
09-15 00:48:49.407: I/GonkDBus(105): DBus Event Loop Starting
09-15 00:48:52.790: W/libdbus(105): A handler is already registered for /B2G/bluetooth/agent
09-15 00:48:52.790: I/GonkDBus(105): RegisterLocalAgent: Can't register object path /B2G/bluetooth/agent for agent!

- successful pairing

- pair fails, crash, infinite rebooting loop
Ok. Repro succeeded on this end too.

Here's the bank of messages we choke on (with my own debug messages added): 


I/Gecko   ( 4483): WARNING: Iterator not type we expect!: file /home/qdot/code/mozbuild/B2G/gecko/dom/bluetooth/linux/BluetoothDBusService.cpp, line 676
I/Gecko   ( 4483): WARNING: Property Name: Connected Property Type Expected: b Property Type Received: a: file /home/qdot/code/mozbuild/B2G/gecko/dom/bluetooth/linux/BluetoothDBusService.cpp, line 684
W/libdbus ( 4483): 4483: assertion failed "dbus_type_is_basic (type)" file "external/dbus/dbus/dbus-marshal-basic.c" line 550 function _dbus_marshal_read_basic
F/libc    ( 4483): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)


Translation: we try to pair with a laptop, and the laptop sends us information about itself in the context of bluetooth. We usually expect connected to be a single boolean value of "yes we're connected to it or no we're not". However, there's a lot of things we could connect to on here. Could be audio, could be file transfer. So, connected comes back as an array instead of a boolean, hence the "Property Type Expected: b Property Type Received: a".

Due to the fact that this is during pairing, we get thru the middle of the pairing process, then crash, but the device is still expecting to pair with us, so once we come back up, it sends us its information again, and we crash again. So that's where the loop comes from.

This will hopefully be a one line fix by early exiting from the property parser when our types don't match.
Assignee: nobody → kyle
Comment on attachment 661475 [details] [diff] [review]
Patch 1 (v1) - Exit early when bluetooth property types don't match

Make sure to note when landing this workaround whether the underlying problem will be fixed in this bug or a followup.
Attachment #661475 - Flags: review?(jones.chris.g) → review+

This isn't a workaround, it /is/ the fix. We don't specifically need the "connected" attribute anyways for the time being.
Target Milestone: --- → mozilla18
Closed: 9 years ago
Resolution: --- → FIXED
Verified fix on 09-16-2012 daily build.   While pairing to desktop still doesn't work, the crash and infinite reboot is fixed.
We wouldn't want this to regress so marking as a blocker.
blocking-basecamp: ? → +
You need to log in before you can comment on or make changes to this bug.