839134 - adb seems to be non-enablable when OTAing across bug 836103 fix time

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Dave Hylands [:dhylands]]

Bug 836103 landed on b2g18 on Jan 30 around 11am, and on the v1.0.0 stream around 2pm.

The observation (by tchung) is that flashing an unagi with a pre-jan 31st image and OTA updating to todays image leaves the phone in a state where adb can't be enabled.

I'm filing this bug to track the investigation and the fix once we figure out what's going on.

Comment 1

[Tony Chung [:tchung]]

And just to state the obvious,  I do have Settings > Developer > Remote debugging checked on.   I've also unplugged/replugged USB, closed/reopened Settings App, and even restarted the phone from scratch.   The Remote debugging checkbox stays checked, but adb devices always returns null.

host-7-31:scripts tchung$ adb devices
List of devices attached 

host-7-31:scripts tchung$ 

Build info from device information screen:
* Git commit: 2013-02-07 11:05:46
7e54ca673277...
BuildID: 2013020707202.

NOte: we also retested an update from yesterday's build to today (02-06 -> 02-07), and adb works as expected.

Comment 2

[Dave Hylands [:dhylands]]

OK I think I've sort of reproduced the problem (but the opposite way).

My STR:

Starting conditions:
- adb was enabled (I had logcat running)
- Remote debugging was off

I downloaded and flashed:
https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/2013/01/2013-01-30-07-02-01/

I went through the FTU app, and the only thing I changed was that I connected to my Wifi network.

Very shortly after booting up, I was presented with an update. I unselected the app update and downloaded/applied. The update that was downloaded was (taken from logcat):

http://update.boot2gecko.org/nightly/b2g_update_20130207070202.mar?build_id=20130207070202&version=18.0 to /mnt/sdcard/updates/0/update.mar

My updated was applied and b2g restarted. The interesting thing is that adb never got disabled. I went into the settings app and toggled the remote debugger setting and no change in adb was observed.

So I think this reproduces the problem (remote debugger setting doesn't seem to be affecting adb) and tchung somehow started with adb disabled.

Now to figure out why...

Comment 3

[Dave Hylands [:dhylands]]

Ok. It seems that this line (from gecko/b2g/chrome/content/settings.js)

    if (Services.prefs.getBoolPref('marionette.defaultPrefs.enabled')) {

throws an exception:

[Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://browser/content/settings.js :: <TOP_LEVEL> :: line 214"  data: no]

And this causes adb to be left in whatever state it was in.

Comment 4

[Dave Hylands [:dhylands]]

Attachment: Add try/catch around query of marionette preference

This adds a try/catch block around the query of marionette.defaultPrefs.enabled.

Comment 5

[Dave Hylands [:dhylands]]

Nominating for tef? since this affects our dogfooders

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 711427 [details] [diff] [review]
Add try/catch around query of marionette preference

[Triage Comment]
Tef wouldn't block release on this, but tracking since it's important to our dogfooding ability and approving for uplift to the mozilla-b2g18 branch for 1.0.1 builds to pick up.

Comment 7

[Dave Hylands [:dhylands]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fc0c13ad85a2

Comment 8

[Dave Hylands [:dhylands]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/2ce85d77e40f

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/fc0c13ad85a2

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: Bugs fixed on b2g18 after 1/25 merge to v1.0 branch are fixed on v1.0.1 branch.