native code crash on Nightly 200711
Categories
(GeckoView :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: kbrosnan, Unassigned)
References
Details
We don't have a great way to get useful info here :-/
Steps to reproduce
Run Firefox Nightly, it will crash on this android phone
Expected behavior
Firefox Nightly runs normally
Actual behavior
Firefox Nightly crashes as soon as it's launched
Device information
-
Android device: Vivax Fun s501, Android Marshmallow 6.0, Mediatek 6580 SOC
-
Fenix version: Nightly 200711 06:00
File attached is adb logcat log
Nightly doesn't crash on a device with the same chipset, but android 7.1.2
|
Reporter | |
Comment 1•6 years ago
|
||
07-13 18:12:00.869 E/mozac/CrashReporter( 4531): CrashHandlerService received native code crash
I see the following, indicating that we are failing to send the report:
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): failed to send report to Socorro
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): java.io.FileNotFoundException: https://crash-reports.mozilla.com/submit?id={eeb82917-e434-4870-8148-5c03d4caa81b}&version=Nightly 200711 06:00&android_component_version=50.0.20200710130140
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:238)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getInputStream(DelegatingHttpsURLConnection.java:210)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at mozilla.components.lib.crash.service.MozillaSocorroService.sendReport$lib_crash_release(MozillaSocorroService.kt:16)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at mozilla.components.lib.crash.service.MozillaSocorroService.report(MozillaSocorroService.kt:8)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at mozilla.components.lib.crash.CrashReporter$submitReport$2.invokeSuspend(CrashReporter.kt:8)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:21)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
07-13 18:12:08.413 E/mozac/MozillaSocorroCra( 4235): at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:11)
07-13 18:12:08.413 I/System.out( 4235): Close in OkHttp
07-13 18:12:08.413 I/mozac/CrashReporter( 4235): Submitted crash to Socorro (id=null, url=null)
07-13 18:12:08.413 I/mozac/CrashReporter( 4235): Crash report submitted to 2 services
Maybe we don't actually have a dump file? Randall was investigating a similar issue with FxR.
Hmm, the stack indicates that we're not trying to do anything with the dump file there. Apparently HttpsURLConnection.getInputStream() will throw FileNotFoundException if there you get a non-2xx response. The crash reporter needs to retry or otherwise deal with this situation.
|
||
Comment 4•6 years ago
|
||
Yeah, retrying is not something we have implemented yet (for Socorro uploads, for Sentry we should get that for free from its library):
https://github.com/mozilla-mobile/android-components/issues/7006
Does the crash upload always fail on that phone? Do we have access to it and can try it multiple times?
|
||
Comment 5•6 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian; :pocmo) from comment #4)
Yeah, retrying is not something we have implemented yet (for Socorro uploads, for Sentry we should get that for free from its library):
https://github.com/mozilla-mobile/android-components/issues/7006Does the crash upload always fail on that phone? Do we have access to it and can try it multiple times?
Hi, I'm the original submitter to on github. And yes, I have tried multiple times and it never sends the crash dump, it doesn't save on the phone either, even with storage permissions before launching Nightly.
|
|
Reporter | |
Comment 6•6 years ago
|
||
Does https://play.google.com/apps/testing/org.mozilla.reference.browser crash in the same way?
Does https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/gecko.v2.mozilla-central.nightly.latest.mobile.android-api-16-opt/artifacts/public/build/geckoview_example.apk crash in the same way?
|
|
||
Comment 7•6 years ago
|
||
(In reply to Kevin Brosnan [:kbrosnan] from comment #6)
Does https://play.google.com/apps/testing/org.mozilla.reference.browser crash in the same way?
Does https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/gecko.v2.mozilla-central.nightly.latest.mobile.android-api-16-opt/artifacts/public/build/geckoview_example.apk crash in the same way?
Reference browser crashes the exact same way as nightly. I captured an adb logcat log again
Geckoview works as expected.
The log in comment #7 was able to successfully post the report here: https://crash-stats.mozilla.org/report/index/d5272f44-bf8b-43ce-8453-260960200714
It looks like Dalvik is segfaulting due to something that's happening during a streaming telemetry dispatch.
Description
•