1213688 - Firefox Android crashes whenever a Sync is initiated, with "GeckPasswordsProvider: Error in NSSBridge" and "java.lang.RuntimeException: java.lang.Exception: PK11SDR_Decrypt returned error -8177: The security password entered is incorrect."

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Android Sync, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: logcat from the crash

On my Nexus 7 tablet (for a while now, at least a few weeks), Firefox Nightly crashes whenever a sync operation is initiated. Finally getting around to filing a but for it.

STR for me on my device (I'm sure there's some profile-specific aspect here so they may not reproduce the bug for others):

 1. Open Nightly
 2. Menu | Settings | Sync
 3. Tap "Sync Now"

ACTUAL RESULTS:
 A dialog appears saying "Unfortunately, Nightly has stopped."

EXPECTED RESULTS:
 Successful sync, no crash/abort/whatever.

Attaching an adb logcat. You can see the Sync operation being initiated The relevant section seems to be the following (with the "Throw" & backtraces repeating over and over and over for some reason):
{
10-11 11:41:06.756 13504 13504 I FxAccounts: fennec :: FirefoxAccounts :: Requesting sync.=
[...]
10-11 11:41:08.343 13697 13713 E GeckoLibLoad: Throw
10-11 11:41:08.343 13697 13713 E GeckPasswordsProvider: Error in NSSBridge
10-11 11:41:08.346 13697 13713 E JavaBinder: *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
10-11 11:41:08.346 13697 13713 E JavaBinder: java.lang.RuntimeException: java.lang.Exception: PK11SDR_Decrypt returned error -8177: The security password entered is incorrect.
10-11 11:41:08.346 13697 13713 E JavaBinder: 
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at org.mozilla.gecko.db.PasswordsProvider.doCrypto(PasswordsProvider.java:247)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at org.mozilla.gecko.db.PasswordsProvider.onPostQuery$3e5a7f14(PasswordsProvider.java:310)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at org.mozilla.gecko.db.SQLiteBridgeContentProvider.query(SQLiteBridgeContentProvider.java:429)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at android.content.ContentProvider.query(ContentProvider.java:1000)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at android.content.ContentProvider$Transport.query(ContentProvider.java:214)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at android.os.Binder.execTransact(Binder.java:446)
10-11 11:41:08.346 13697 13713 E JavaBinder: Caused by: java.lang.Exception: PK11SDR_Decrypt returned error -8177: The security password entered is incorrect.
10-11 11:41:08.346 13697 13713 E JavaBinder: 
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at org.mozilla.gecko.NSSBridge.nativeDecrypt(Native Method)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at org.mozilla.gecko.NSSBridge.decrypt(NSSBridge.java:44)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	at org.mozilla.gecko.db.PasswordsProvider.doCrypto(PasswordsProvider.java:242)
10-11 11:41:08.346 13697 13713 E JavaBinder: 	... 6 more
10-11 11:41:08.346 13504 13718 E FxAccounts: fennec :: PasswordsRepoSession :: Got null cursor exception in PasswordsRepoSession.store
10-11 11:41:08.348 13504 13718 W FxAccounts: fennec :: SynchronizerSession :: First RecordsChannel onFlowStoreFailed. Logging local store error.
10-11 11:41:08.348 13504 13718 W FxAccounts: org.mozilla.gecko.sync.repositories.NullCursorException
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at org.mozilla.gecko.sync.repositories.android.RepoUtils$QueryHelper.checkAndLogCursor(RepoUtils.java:86)
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at org.mozilla.gecko.sync.repositories.android.RepoUtils$QueryHelper.safeQuery(RepoUtils.java:65)
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at org.mozilla.gecko.sync.repositories.android.PasswordsRepositorySession.retrieveByGUID(PasswordsRepositorySession.java:566)
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at org.mozilla.gecko.sync.repositories.android.PasswordsRepositorySession.access$1200(PasswordsRepositorySession.java:38)
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at org.mozilla.gecko.sync.repositories.android.PasswordsRepositorySession$5.run(PasswordsRepositorySession.java:272)
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
10-11 11:41:08.348 13504 13718 W FxAccounts: 	at java.lang.Thread.run(Thread.java:818)
10-11 11:41:08.351 13697 13714 E GeckoLibLoad: Throw
10-11 11:41:08.351 13697 13714 E GeckPasswordsProvider: Error in NSSBridge
10-11 11:41:08.352 13697 13714 E JavaBinder: *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
10-11 11:41:08.352 13697 13714 E JavaBinder: java.lang.RuntimeException: java.lang.Exception: PK11SDR_Decrypt returned error -8177: The security password entered is incorrect.
}


NIGHTLY VERSION: 44.0a1 (2015-10-09)

Comment 1

[Daniel Holbert [:dholbert]]

I have a Master Password on this Nightly profile; that seems like it may be related to "The security password is incorrect" message.

That's not (on its own) entirely responsible, though, because I also have a Master Password on my OnePlus One phone, and I've never hit this issue there.

I'm running CyanogenMod 12.1 nightlies on the Nexus 7 (and also on my non-reproducing OnePlus One)

Comment 2

[Daniel Holbert [:dholbert]]

This makes Firefox Nightly basically unusable on this device, because it crashes within a minute of two of starting up (due to a Sync being initiated in the background and tripping over this bug).

Comment 3

[Nick Alexander :nalexander [he/him]]

(In reply to Daniel Holbert [:dholbert] (less responsive Oct 9-12 & 15-18) from comment #2)
> This makes Firefox Nightly basically unusable on this device, because it
> crashes within a minute of two of starting up (due to a Sync being initiated
> in the background and tripping over this bug).

dholbert: you can stop Firefox from syncing by going to Android Settings > Accounts > Nightly > [select account] and unchecking the checkbox.  Let's co-ordinate to look at your DB next week.

Comment 4

[Daniel Holbert [:dholbert]]

Sounds good, just did that [probably making Nightly usable again, hooray!]

Thanks for the quick response & for being up for some remote poking around -- pretty much any time Tues or Weds would be good for me to take a look at the DB together.  I'll ping you on Tuesday at some point, or feel free to ping me whenever's good.

Comment 5

[Richard Newman [:rnewman]]

Note that we don't support master password + Sync on Android at all: Bug 711636.

Bug 946857 would make it easier for us to do so, as well as eliminating basically all of the code involved with this bug.

We can either go ahead and fix that for 45/46/whenever and bandaid this crash, or we can just do the bandaid and continue to ignore this collection of features altogether. Margaret, please opine!

Given that password sync on Android is really unreliable (as Margaret has seen personally) due to this flaky multi-process NSS bridge stuff, I'm in favor of the former, and continue to volunteer to mentor someone through it.

Comment 6

[:Margaret Leibovic]

(In reply to Richard Newman [:rnewman] from comment #5)
> Note that we don't support master password + Sync on Android at all: Bug
> 711636.
> 
> Bug 946857 would make it easier for us to do so, as well as eliminating
> basically all of the code involved with this bug.
> 
> We can either go ahead and fix that for 45/46/whenever and bandaid this
> crash, or we can just do the bandaid and continue to ignore this collection
> of features altogether. Margaret, please opine!
> 
> Given that password sync on Android is really unreliable (as Margaret has
> seen personally) due to this flaky multi-process NSS bridge stuff, I'm in
> favor of the former, and continue to volunteer to mentor someone through it.

I'm in favor of finding a way to prioritize bug 946857 to have password sync work reliably. I think it's probably more important to invest in that than in some of the other password-related work that's currently in our backlog.

As for MP, I'm not sure about whether we should try to support that. I know that we've under-invested in the experience on desktop, and I don't know that it makes sense for us to invest in it on mobile.

Comment 7

[Richard Newman [:rnewman]]

(In reply to :Margaret Leibovic from comment #6)

> I'm in favor of finding a way to prioritize bug 946857 to have password sync
> work reliably. I think it's probably more important to invest in that than
> in some of the other password-related work that's currently in our backlog.

OK, great; we're on the same page. Let's do it: it's a tractable project that'll give big reliability, memory usage, and technical debt payoffs.

Barbara: count this as a big +2 from us.


> As for MP, I'm not sure about whether we should try to support that. I know
> that we've under-invested in the experience on desktop, and I don't know
> that it makes sense for us to invest in it on mobile.

There would likely be screams from whatever users we have (telemetry?). Master Password continues to exist because enough people want it for _something_ (PIN lock? better-than-cleartext passwords on disk?) and there aren't great alternatives in the browser. But lots of us hate it and recognize that the current implementation sucks.

If we shift this into Java as part of Bug 946857 we'd be more easily able to implement things like Bug 993077, allowing us to turn to face whatever value our mobile users are getting out of master password.

On iOS we've talked about supporting TouchID for access to private tabs, passwords, etc. etc., so that would follow the same vein.

In the mean time it's straightforward enough to keep feature parity, and just getting all this stuff to live in Java fixes most of the blockers for Sync + MP.

Comment 8

[Barbara Bermes [:barbara] - NI please!]

By solving Bug 946857, we would prepare ourselves for any upcoming password sync work in general but not the syncing of MP? (Bug 711636)

Could somebody please elaborate on the advantages of doing 946857? a) it would not fix this bug here b) pre-requisite for MP and sync c) more secure password storage d)...?

I'm a bit hesitant to put too much effort into Master password (as Margaret also pointed out) at this point, considering that the security team (including Tanvi, Javaun) are looking into revisting the functionality of master password, so we should keep an eye on that as it applies to us.

Comment 9

[Richard Newman [:rnewman]]

(In reply to Barbara Bermes [:barbara] from comment #8)
> By solving Bug 946857, we would prepare ourselves for any upcoming password
> sync work in general but not the syncing of MP? (Bug 711636)

It prepares us for everything. It would make using MP with Sync much more straightforward.

As I noted in Comment 7: "just getting all this stuff to live in Java fixes most of the blockers for Sync + MP."


> Could somebody please elaborate on the advantages of doing 946857? a) it
> would not fix this bug here b) pre-requisite for MP and sync c) more secure
> password storage d)...?

* Syncing of passwords (ignoring MP altogether) would actually function. Right now it seems to be pretty broken even for non-MP users.

* Much better starting point to implement Bug 1098501, which would bring password conflict resolution up to parity with iOS.

* Better perf: no need for IPC, eliminate sqlite for storage of passwords.

* Better memory footprint: no need for a second Android process. This will be at least 8MB, could be *huge*.

* More secure password storage: we can discard the limitations of the existing login manager storage.

* Password storage code that's actually maintained: the sqlite nsILoginManagerStorage implementation is deprecated and only used by Fennec.

* Opportunity to use better protection technologies -- master password equivalent, or something more usable.


> I'm a bit hesitant to put too much effort into Master password (as Margaret
> also pointed out) at this point, considering that the security team
> (including Tanvi, Javaun) are looking into revisting the functionality of
> master password, so we should keep an eye on that as it applies to us.

Almost none of the motivation for doing this work is to make MP work -- it's to make everything else work. Having the opportunity to make MP fail nicely/detectably is great, and having it work at all, or work better, is a nice side-effect.

Comment 10

[Daniel Holbert [:dholbert]]

(side-note that I forgot to mention earlier: this bug's crashes do *not* generate a crash report -- at least, they don't show up in about:crashes at all.)

Comment 11

[Nick Alexander :nalexander [he/him]]

(In reply to Daniel Holbert [:dholbert] (less responsive Oct 9-12 & 15-18) from comment #10)
> (side-note that I forgot to mention earlier: this bug's crashes do *not*
> generate a crash report -- at least, they don't show up in about:crashes at
> all.)

I believe they would if you were on Release or Beta, where we capture background service hangs and crashes.

Comment 12

[Daniel Holbert [:dholbert]]

The "relevant section" I quoted in comment 0 is not actually relevant, I think -- that's just the Sync client correctly handling an exception.

The *real* relevant section is this:
{
10-11 11:41:10.234 13697 13730 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 13730 (Binder_4)
10-11 11:41:10.235   198   198 I DEBUG   : property debug.db.uid not set; NOT waiting for gdb.
10-11 11:41:10.235   198   198 I DEBUG   : HINT: adb shell setprop debug.db.uid 100000
10-11 11:41:10.235   198   198 I DEBUG   : HINT: adb forward tcp:5039 tcp:5039
10-11 11:41:10.338   198   198 I DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-11 11:41:10.338   198   198 I DEBUG   : Build fingerprint: 'google/razor/flo:5.1.1/LMY48M/2167285:user/release-keys'
10-11 11:41:10.338   198   198 I DEBUG   : Revision: '0'
10-11 11:41:10.338   198   198 I DEBUG   : ABI: 'arm'
10-11 11:41:10.339   198   198 I DEBUG   : pid: 13697, tid: 13730, name: Binder_4  >>> org.mozilla.fennec.PasswordsProvider <<<
10-11 11:41:10.339   198   198 I DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
10-11 11:41:10.363   198   198 I DEBUG   :     r0 fffffff8  r1 00000000  r2 0000018f  r3 d0000000
10-11 11:41:10.363   198   198 I DEBUG   :     r4 00000000  r5 ae838ac0  r6 00000001  r7 aefff6ac
10-11 11:41:10.363   198   198 I DEBUG   :     r8 00000000  r9 aefff65c  sl 00000000  fp 132e83d0
10-11 11:41:10.363   198   198 I DEBUG   :     ip ffffffff  sp aefff648  lr b355116d  pc b6e4bc24  cpsr 40000030
10-11 11:41:10.364   198   198 I DEBUG   : 
10-11 11:41:10.364   198   198 I DEBUG   : backtrace:
10-11 11:41:10.364   198   198 I DEBUG   :     #00 pc 00011c24  /system/lib/libc.so (strlen+35)
10-11 11:41:10.364   198   198 I DEBUG   :     #01 pc 0003d169  /data/app/org.mozilla.fennec-1/lib/arm/libmozglue.so (doCrypto(_JNIEnv*, char const*, char const*, char**, bool)+152)
10-11 11:41:11.152   198   198 I DEBUG   : 
10-11 11:41:11.152   198   198 I DEBUG   : Tombstone written to: /data/tombstones/tombstone_07
10-11 11:41:11.135 13730 13730 W Binder_4: type=1701 audit(0.0:188): auid=4294967295 uid=10069 gid=10069 ses=4294967295 subj=u:r:untrusted_app:s0 reason="memory violation" sig=11
10-11 11:41:11.153   566   596 I BootReceiver: Copying /data/tombstones/tombstone_07 to DropBox (SYSTEM_TOMBSTONE)
10-11 11:41:11.183 13504 13718 W FxAccounts: fennec :: PasswordsRepoSession :: Unexpectedly updated -1 rows for guid {3002e217-eed8-44d6-816f-59245bb7b243}
10-11 11:41:11.186 13504 13718 W FxAccounts: fennec :: SynchronizerSession :: First RecordsChannel onFlowStoreFailed. Logging local store error.
10-11 11:41:11.186 13504 13718 W FxAccounts: android.os.DeadObjectException
}

The "Unexpectedly updated -1 rows for guid" line is particularly interesting, and hints at something being maybe-broken w.r.t. that GUID.

I queried my signons.sqlite file, and discovered that this GUID {3002e217-eed8-44d6-816f-59245bb7b243} is in my moz_deleted_logins table, and is *not* in my moz_logins table.

Comment 13

[Daniel Holbert [:dholbert]]

...but on a different device (my phone, which has been syncing correctly), my moz_deleted_logins table is empty, and this GUID *does* exist in my moz_logins table.

So I'm guessing I may have deleted this login locally on my tablet, and then the server had a pending change to that same record, and we're trying & failing to sync that change because the record is missing. Or something like that.

Comment 14

[Daniel Holbert [:dholbert]]

Also: I still get this same issue (with "Unexpectedly updated -1 rows for guid") after removing my master password. So this isn't master-password related.

Comment 15

[Vivek Balakrishnan[:vivek]]

Attachment: MozReview Request: Bug 1213688 : Update password store logic for deleted local records r?nalexander,rnewman

Bug 1213688 : Update password store logic for deleted local records r?nalexander,rnewman

Comment 16

[Richard Newman [:rnewman]]

Comment on attachment 8676370 [details]
MozReview Request: Bug 1213688 : Update password store logic for deleted local records r?nalexander,rnewman

https://reviewboard.mozilla.org/r/22665/#review20157

I like it! Nice work.

::: mobile/android/base/sync/repositories/android/PasswordsRepositorySession.java:371
(Diff revision 1)
> +          return;

I have a sneaking suspicion that the logic around line 321 needs to apply here, too.

Comment 17

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8676370 [details]
MozReview Request: Bug 1213688 : Update password store logic for deleted local records r?nalexander,rnewman

https://reviewboard.mozilla.org/r/22665/#review20189

rnewman correctly points out an issue, which I think we should leave for now and address in Bug 1098501.

Suppose the local client has a very fast local clock, has a single deleted record, and syncs successfully.  So `L = {(guid, timestamp_in_future)}` and the server is the same.

Suppose a remote client has a correct clock and modifies the record, uploading it successfully.  So `R = {(guid, timestamp)}`, the server is the same, and `timestamp < timestamp_in_future`.

When the local client downloads the incoming record, it will observe that the remote record is not deleted, but it's older than the local record.  The patch under review drops the incoming record on the floor.  **This is wrong**: the local client should force-upload the local record, so that the server is consistent.

Fixing this would entail writing a new timestamp to the local database; or tracking the GUIDs that need re-uploading.  Neither is trivial, so let's leave that to Bug 1098501.  This works around a bad crash, so ship it!

Comment 18

[Richard Newman [:rnewman]]

This is a good example of why we shouldn't compare timestamps (particularly ones from different devices, as in this case) for reconciling if we can ever avoid it; the current behavior is *inconsistent* rather than wrong, but having an older deletion silently beat a remote change because of clock skew is *wrong*.

(Granted, a user who deletes a password on one device then saves a change on another might be argued to get what they deserve, but remember that they aren't in control of whether Firefox 'reuses' a GUID!)

Doing a three-way merge will avoid some situations in which it's necessary to compare timestamps (not deletions, unfortunately). 

Tracking explicit change flags as we do on iOS, rather than relying on modified times, avoids some others -- e.g., a from-the-future deletion that was already synced up, versus a new-from-the-present change with the same GUID.

Beyond that we'd need to get clever with server timestamp mappings or move on to something else entirely.

Comment 19

[Vivek Balakrishnan[:vivek]]

https://hg.mozilla.org/integration/fx-team/rev/a0b901ae875a273a8cbb090291bc388c7a65f5be
Bug 1213688 : Update password store logic for deleted local records r=nalexander,rnewman

Comment 20

[Nick Alexander :nalexander [he/him]]

dholbert: this will ride out to central tonight.  Could you make sure to update and test syncing against this patch?  Thanks!

Comment 21

[Daniel Holbert [:dholbert]]

Will do. Thanks!

(I just verified that I can still reproduce this w/ latest nightly right now, too.)

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 23

[Daniel Holbert [:dholbert]]

Yup, the crash seems to have gone away in the latest nightly (2015-10-22)

I do still get a bunch of error output in logcat, like:
  fennec :: PasswordsRepoSession :: Got null cursor exception in PasswordsRepoSession.store

and the following chunk:
====
0-22 13:13:40.602 19812 20234 W FxAccounts: fennec :: ServLocSynchronizerSess :: Got 7 failures storing local records! Ignoring local store failures and continuing synchronizer session.
10-22 13:13:40.914   578   617 I Timeline: Timeline: Activity_windows_visible id: ActivityRecord{1d38c83f u0 org.mozilla.fennec/org.mozilla.gecko.fxa.activities.FxAccountStatusActivity t1310} time:52570045
10-22 13:13:41.387 20209 20240 E GeckoLibLoad: Throw
10-22 13:13:41.387 20209 20240 E GeckoPasswordsProvider: Error in NSSBridge
10-22 13:13:41.388 20209 20240 E JavaBinder: *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
10-22 13:13:41.388 20209 20240 E JavaBinder: java.lang.RuntimeException: java.lang.Exception: PK11SDR_Decrypt returned error 0: Success
10-22 13:13:41.388 20209 20240 E JavaBinder: 
10-22 13:13:41.388 20209 20240 E JavaBinder:    at org.mozilla.gecko.db.PasswordsProvider.doCrypto(PasswordsProvider.java:247)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at org.mozilla.gecko.db.PasswordsProvider.onPostQuery$3e5a7f14(PasswordsProvider.java:310)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at org.mozilla.gecko.db.SQLiteBridgeContentProvider.query(SQLiteBridgeContentProvider.java:429)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at android.content.ContentProvider.query(ContentProvider.java:1000)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at android.content.ContentProvider$Transport.query(ContentProvider.java:214)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:112)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at android.os.Binder.execTransact(Binder.java:446)
10-22 13:13:41.388 20209 20240 E JavaBinder: Caused by: java.lang.Exception: PK11SDR_Decrypt returned error 0: Success
10-22 13:13:41.388 20209 20240 E JavaBinder: 
10-22 13:13:41.388 20209 20240 E JavaBinder:    at org.mozilla.gecko.NSSBridge.nativeDecrypt(Native Method)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at org.mozilla.gecko.NSSBridge.decrypt(NSSBridge.java:44)
10-22 13:13:41.388 20209 20240 E JavaBinder:    at org.mozilla.gecko.db.PasswordsProvider.doCrypto(PasswordsProvider.java:242)
10-22 13:13:41.388 20209 20240 E JavaBinder:    ... 6 more
====

But the crash is fixed, and I completed a sync successfully enough to have my "last sync" date be updated to "0 minutes ago", so I think this bug is indeed FIXED. Hooray!

Comment 24

[Nick Alexander :nalexander [he/him]]

(In reply to Daniel Holbert [:dholbert] from comment #23)
> Yup, the crash seems to have gone away in the latest nightly (2015-10-22)
> 
> I do still get a bunch of error output in logcat, like:
>   fennec :: PasswordsRepoSession :: Got null cursor exception in
> PasswordsRepoSession.store
> 
> and the following chunk:
> ====
> 0-22 13:13:40.602 19812 20234 W FxAccounts: fennec ::
> ServLocSynchronizerSess :: Got 7 failures storing local records! Ignoring
> local store failures and continuing synchronizer session.
> 10-22 13:13:40.914   578   617 I Timeline: Timeline:
> Activity_windows_visible id: ActivityRecord{1d38c83f u0
> org.mozilla.fennec/org.mozilla.gecko.fxa.activities.FxAccountStatusActivity
> t1310} time:52570045
> 10-22 13:13:41.387 20209 20240 E GeckoLibLoad: Throw
> 10-22 13:13:41.387 20209 20240 E GeckoPasswordsProvider: Error in NSSBridge
> 10-22 13:13:41.388 20209 20240 E JavaBinder: *** Uncaught remote exception! 
> (Exceptions are not yet supported across processes.)
> 10-22 13:13:41.388 20209 20240 E JavaBinder: java.lang.RuntimeException:
> java.lang.Exception: PK11SDR_Decrypt returned error 0: Success

So, this looks pretty terrible.  The code in question NSSBridge.cpp and the underlying NSS function, have changed in ages.  jchen, can you suggest a way to understand what's really happening here?

Comment 25

[Daniel Holbert [:dholbert]]

I spun off bug 1217588 for the logcat issues quoted in comment 23. Transferring ni=jchen to that bug.