Closed Bug 791413 Opened 12 years ago Closed 12 years ago

Attempting to pair Otoro to a macbookair will crash immediately

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: tchung, Assigned: qdot)

References

Details

(Keywords: crash)

Attachments

(2 files)

Attached file logcat of BT pair crash (deleted) —
When trying to pair Otoro to a MacbookAir, the device will immediately crash and self restart itself. Logcat attached. Environment: - 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"/> Repro: 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/init.qcom.bt.sh: 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/init.qcom.bt.sh: start hciattach 09-15 00:48:49.307: I/qcom-bluetooth(621): /system/etc/init.qcom.bt.sh: 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! Expected: - successful pairing Actual: - 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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/1f2068fe29a8 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
Status: NEW → RESOLVED
Closed: 12 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.
Status: RESOLVED → VERIFIED
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.

Attachment

General

Created:
Updated:
Size: