1588092 - glean-core fails to handle accumulation before Glean is initialized

Status: RESOLVED FIXED

(Data Platform and Tools :: Glean: SDK, defect, P1)

Description

[Alessio Placitelli [:Dexter]]

If lib-crash (from A-C) detects previous crash data, it will attempt to accumulate stuff in Glean. When using glean-core, this fails. In debug mode, it crashes with the following stack:

2019-10-11 15:58:03.238 5031-5031/? E/AndroidRuntime: FATAL EXCEPTION: main
Process: org.mozilla.fenix, PID: 5031
java.lang.ExceptionInInitializerError
at mozilla.components.lib.crash.service.GleanCrashReporterService.<init>(GleanCrashReporterService.kt:24)
at org.mozilla.fenix.components.Analytics$crashReporter$2.invoke(Analytics.kt:4)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:6)
at org.mozilla.fenix.components.Analytics.getCrashReporter(Unknown Source:7)
at org.mozilla.fenix.FenixApplication.setupApplication(FenixApplication.kt:1)
at org.mozilla.fenix.FenixApplication.onCreate(FenixApplication.kt:2)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1154)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5920)
at android.app.ActivityThread.access$1100(ActivityThread.java:200)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1656)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6718)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Caused by: java.lang.NullPointerException: throw with null exception
at mozilla.telemetry.glean.private.CounterMetricType.<init>(CounterMetricType.kt:7)
at mozilla.components.lib.crash.GleanMetrics.CrashMetrics.<clinit>(CrashMetrics.kt:5)
at mozilla.components.lib.crash.service.GleanCrashReporterService.<init>(GleanCrashReporterService.kt:24) 
at org.mozilla.fenix.components.Analytics$crashReporter$2.invoke(Analytics.kt:4) 
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:6) 
at org.mozilla.fenix.components.Analytics.getCrashReporter(Unknown Source:7) 
at org.mozilla.fenix.FenixApplication.setupApplication(FenixApplication.kt:1) 
at org.mozilla.fenix.FenixApplication.onCreate(FenixApplication.kt:2) 
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1154) 
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5920) 
at android.app.ActivityThread.access$1100(ActivityThread.java:200) 
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1656) 
at android.os.Handler.dispatchMessage(Handler.java:106) 
at android.os.Looper.loop(Looper.java:193) 
at android.app.ActivityThread.main(ActivityThread.java:6718) 
at java.lang.reflect.Method.invoke(Native Method) 
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) 
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858) 

I'm able to reproduce this locally in a sample app, and I get the following additional lines:

D/libglean_ffi: glean_ffi: Android logging should be hooked up!
W/libglean_ffi: ffi_support::handle_map: Illegal handle! 0

Comment 1

[Alessio Placitelli [:Dexter]]

This is due to the fact that the get method for LabeledMetricType requires a Glean handle, which is not available yet close to startup.

Unfortunately, this affects UuidMetricType and TimingDistributionMetricType as well.

Comment 2

[Alessio Placitelli [:Dexter]]

The labeled metric types bug is present in A-C as well but, since we're lucky, doesn't cause any startup crash.

When using label metric types with a dynamic label, we trip this code that loads any previously seen label. When that is used before Glean is initialized, it will fail because the StorageEngineManager is initialized by Glean init. During its init, the Context is set (it is required for loading SharedPreferences). So, without init, we should crash.

However, we don't crash because we wrap access to the stored data here. The result? We simply pretend no label was stored and move on with the current recording, at least in A-C. In glean-core, even in release, we'd drop all the data on the ground.

Comment 3

[Jan-Erik Rediger [:janerik]]

Attachment: GitHub Pull Request

Comment 4

[Jan-Erik Rediger [:janerik]]

Attached PR is one step in that direction.