[b2g-bluetooth] Disabling bluetooth in settings app crashes main process

RESOLVED FIXED in mozilla18

Status

()

Core
General
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: cjones, Assigned: qdot)

Tracking

unspecified
mozilla18
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

This didn't used to happen, so I suspect without any evidence bluetooth.
Disabling airplane mode after it's already on doesn't crash the b2g process.
If I don't enter airplane mode, but just disable bluetooth, crash.  Sorry :(.
Summary: Enabling airplane mode in OOP settings app crashes main process → Disabling bluetooth in OOP settings app crashes main process
This should become a basecamp-blocker, as we're about to run Settings Out Of Process: https://github.com/mozilla-b2g/gaia/pull/4728
blocking-basecamp: --- → ?
Hm. I have tested this a bunch on desktop, is this something unique to the phone maybe? I can't reproduce and there's no stack or anything to go on here...
Only tested on phone.  Didn't have time for a stack yesterday.
blocking-basecamp: ? → +
Can confirm happening on phone and not on desktop, was happening before OOP landed too.
Assignee: nobody → kyle
Do you mean OOP'ing of bluetooth, or of the settings app?
My reading of comment 6 is that this is a preexisting condition for in-process bluetooth.  Please correct if that's wrong.
Summary: Disabling bluetooth in OOP settings app crashes main process → Disabling bluetooth in settings app crashes main process
Blocks: 727618
No longer blocks: 745143
Summary: Disabling bluetooth in settings app crashes main process → [b2g-bluetooth] Disabling bluetooth in settings app crashes main process
Repro update: this doesn't happen when bluetooth is disabled from the pulldown menu. Just happens in the settings app.
Ok, multiple issues here:

- Whenever we get a dbus signal that we don't have any specific action for ("DefaultAdapterChanged", for instance), we just fall out the bottom of our if/else block but still try to distribute the signal, which we never actually stored anywhere.
- Even after that's fixed, we still crash. That's because there's a sDefaultAdapterPath variable that used to store the path of the Adapter after an AdapterAdded signal is sent. This is all well and good when the AdapterAdded signal is actually sent. However, say B2G is taken down and comes back up without rebooting. gecko will enable bluetooth, but it was never disabled, so nothing happens, no new AdapterAdded signal is sent, path is never filled in.
Ok. Reserved record service registration is straight out wrong. Removing for now to fix crasher, will file followup.
Created attachment 661471 [details] [diff] [review]
Patch 1 (v1) - Exit signal filters early when signal not handled, remove service reg/unreg to fix bt crashes
Attachment #661471 - Flags: review?(dhylands)
Attachment #661471 - Flags: review?(dhylands) → review+
Blocks: 791436
https://hg.mozilla.org/integration/mozilla-inbound/rev/5a97a9589e7c
Target Milestone: --- → mozilla18
https://hg.mozilla.org/mozilla-central/rev/5a97a9589e7c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.