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 :(.

This should become a basecamp-blocker, as we're about to run Settings Out Of Process: https://github.com/mozilla-b2g/gaia/pull/4728

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.

Can confirm happening on phone and not on desktop, was happening before OOP landed too.

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.

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.