1988188 - startup Crash in [@ mozilla.appservices.logins.InternalException: at mozilla.appservices.logins.LoginsKt.uniffiCheckCallStatus(logins.kt:40)]

Status: REOPENED

(Firefox for Android :: Logins, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Frequent startup crash, Firefox for Android 144.0a1 has 81 crashes from 84 installs, first reported build is 20250905210909.

Crash report: https://crash-stats.mozilla.org/report/index/d8f0767a-5251-4679-bd6c-432460250911

Top 10 frames:

0  mozilla.appservices.logins.LoginsKt  uniffiCheckCallStatus  logins.kt:40
1  mozilla.appservices.logins.LoginsKt  access$uniffiCheckCallStatus  logins.kt:1
2  mozilla.appservices.logins.LoginsKt  checkCanary  logins.kt:49
3  mozilla.components.service.sync.logins.LoginsCrypto  isKeyRecoveryNeeded  LoginsCrypto.kt:3
4  mozilla.components.concept.storage.KeyManager  getManagedKey  KeyManager.kt:13
5  mozilla.components.concept.storage.KeyManager  getOrGenerateKey$suspendImpl  KeyManager.kt:92
6  mozilla.components.service.sync.logins.SyncableLoginsStorage$conn$1  invokeSuspend  SyncableLoginsStorage.kt:49
7  kotlin.coroutines.jvm.internal.BaseContinuationImpl  resumeWith  ContinuationImpl.kt:9
8  kotlinx.coroutines.DispatchedTask  run  DispatchedTask.kt:122
9  kotlinx.coroutines.internal.LimitedDispatcher$Worker  run  LimitedDispatcher.kt:4

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox for Android::Logins' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Donal Meehan [:dmeehan]]

Tracking as requested but this matches up with when Bug 1985845 landed.
There are reports on 141.0.3 also, so not sure if this was introduced in 144?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox144 (nightly). However, the bug still isn't assigned and has low severity.

:avirvara, could you please find an assignee and increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 4

[Mark Hammond [:markh] [:mhammond]]

It looks like this code is catching a specific exception, but the code is failing with a different exception and presumably not being caught anywhere up the stack. I suspect the failing error is going to be some IO error - maybe "sqlite db is corrupt" or similar.

Comment 5

[Alexandra Virvara]

Attachment: Bug 1988188: exception handle for key validity check

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/28a6561d7798
https://hg.mozilla.org/integration/autoland/rev/2a3980a196ee
exception handle for key validity check r=android-reviewers,matt-tighe

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/2a3980a196ee

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:avirvara, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox144 to wontfix.

For more information, please visit BugBot documentation.

Comment 9

[Donal Meehan [:dmeehan]]

:avirvara, as mentioned in Comment 2, there were reports on 141.0.3 also. From your fix, do you know the regressor OR which version were affected?
We can take a beta uplift request, but I wanted to know if there was anything else needed.

Comment 10

[Alexandra Virvara]

This is not a necessary a regression in 144, the problem might have been there before (don't know the regressor). The code that crashes tries to catch a specific exception (and before the latest change it tried to catch another specific exception). I replaced it with the general one (that includes the other two) because this one is actually declared to be thrown by the failing method.

Comment 11

[Donal Meehan [:dmeehan]]

(In reply to Alexandra Virvara from comment #10)

This is not a necessary a regression in 144, the problem might have been there before (don't know the regressor). The code that crashes tries to catch a specific exception (and before the latest change it tried to catch another specific exception). I replaced it with the general one (that includes the other two) because this one is actually declared to be thrown by the failing method.

Alexandara, any concerns with submitting a beta uplift request, or should this ride the train with Fx145?

Comment 12

[Alexandra Virvara]

no, there aren't any concerns

Comment 13

[Alexandra Virvara]

Comment on attachment 9514017 [details]
Bug 1988188: exception handle for key validity check

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: the added code catches all exceptions that the problematic method call might throw and the app won't crash anymore
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This fix catches all the exceptions that might be thrown by the problematic method call
• String changes made/needed:
• Is Android affected?: Yes

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Are we sure this is fixed? Looks like there's still a decent volume of crashes coming in from recent Nightly builds which should have this fix included.

Comment 15

[Mark Hammond [:markh] [:mhammond]]

Is the stack identical? I'm not sure the patch is actually correct - it will treat this error as though the keys are wrong and attempt to fix them - and the fix would probably hit the exact same problem from a slightly different place.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

All recent reports look like this:

mozilla.appservices.logins.InternalException: NSS has not initialized.
    Please ensure you include the initialization component and call it early in your code. See
    https://mozilla.github.io/application-services/book/rust-docs/init_rust_components/index.html
	at mozilla.appservices.logins.LoginsKt.uniffiCheckCallStatus(logins.kt:40)
	at mozilla.appservices.logins.LoginsKt.access$uniffiCheckCallStatus(logins.kt:1)
	at mozilla.appservices.logins.LoginsKt.checkCanary(logins.kt:50)
	at mozilla.components.service.sync.logins.LoginsCrypto.isKeyRecoveryNeeded(LoginsCrypto.kt:3)
	at mozilla.components.concept.storage.KeyManager.getManagedKey(KeyManager.kt:13)
	at mozilla.components.concept.storage.KeyManager.getOrGenerateKey$suspendImpl(KeyManager.kt:92)
	at mozilla.components.service.sync.logins.SyncableLoginsStorage$conn$1.invokeSuspend(SyncableLoginsStorage.kt:49)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:9)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:122)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:4)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:3)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:94)
	Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: null

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on nightly

For more information, please visit BugBot documentation.

Comment 18

[Alexandra Virvara]

The fix catches the error being thrown in the first place, but I think it should be handled separately by making sure that the NSS library is initialised before trying to validate the key.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

No crash reports from Nightly builds with the fix for bug 1989865 included so far.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

The exception is different, but I wonder if this is related to bug 1989864 still.

Comment 21

[Alexandra Virvara]

it seems to be related to bug 1989865, let's observe the behaviour with it being fixed.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Crash volume is down significantly since bug 1989865 landed, but not completely eliminated.