Chrome crashes due to trace event issue in OmahaService |
|||||||||||
Issue description
Chrome Version: Canary 66.0.3356.0
OS: Android (8.1.0) on Pixel 2
I can reliably reproduce this issue when starting VR, and thought they were directly linked. But then, when out of VR and navigating to Settings to get the OS version, I saw the same crash. It feels like VR is inducing a crash that may otherwise happen anyway.
To reproduce the problem, one method is:
(1) Load the Canary build
(2) Start Chrome
(3) Enter VR using a headset
The Java crash trace is:
Shutting down VM
FATAL EXCEPTION: main
Process: com.chrome.canary, PID: 6188
java.lang.IllegalArgumentException: Multiple pending trace events can't have the same name
at org.chromium.base.EarlyTraceEvent.begin(EarlyTraceEvent.java:30)
at org.chromium.base.TraceEvent.begin(TraceEvent.java:48)
at org.chromium.components.background_task_scheduler.BackgroundTaskSchedulerImpl.schedule(BackgroundTaskSchedulerImpl.java:24)
at org.chromium.chrome.browser.omaha.OmahaService.scheduleJobService(OmahaService.java:24)
at org.chromium.chrome.browser.omaha.OmahaService.startServiceImmediately(OmahaService.java:11)
at org.chromium.chrome.browser.PowerBroadcastReceiver$ServiceRunnable.run(PowerBroadcastReceiver.java:16)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
,
Feb 28 2018
I can't repro this on my personal Pixel 1, but I can on my development Pixel 2 (non-XL).
,
Feb 28 2018
I can't repro on my dev Pixel 1 and my personal Pixel 2 (both non-XL).
,
Feb 28 2018
,
Feb 28 2018
,
Feb 28 2018
FWIW, the repro seems to be non-deterministic. However, I saw the same one-off crash 1 to 2 months ago, but didn't look deeply at the time, so it's not new. If anyone needs help grabbing more logs, please let me know.
,
Mar 1 2018
fgorski@, do you have any idea since you touched the code at some point? nyquist@ is out traveling and dfalcantara@ is not working on Chrome anymore.
,
Mar 5 2018
At first look this seems weird. We're asserting that we're on the UI thread, but we're still invoking BackgroundTaskScheduler#schedule(...) again somehow while there. It would have been nice to be able to see what the initial invocation was.
,
Mar 5 2018
Tommy, I can still readily repro this using Chrome Canary (67.0.3362). I'll attach an Android BugReport. I don't know why it's easier for me to repro than others, but, let me know if there's anything I can do to help root-cause this.
,
Mar 5 2018
,
Mar 14 2018
Hah, I just realized what's going on. The problem happens when I have Chromium (a dev build), and Chrome Canary open simultaneously. More specifically, if I have a Chromium developer build running, task switch to the launcher and fire up Chrome Canary, things are in a bad place. The crash will probably happen some time after that, but if you just pop into VR, the crash will happen immediately.
,
Mar 14 2018
I should clarify - by dev/developer build, I mean "a build I made myself", not a -dev channel build.
,
Mar 14 2018
FWIW, I just tried simultaneous Chrome stable and canary, and don't see the issue.
,
Mar 14 2018
That sounds like it's worth looking into. Is the VR service somehow shared between apps? Is there anything related to signing the package going on here?
,
Mar 14 2018
I still can't repro. Each Chrome channel should have its own copy of the component.
,
Mar 16 2018
For the record: - I can't repro this with the same builds on a Pixel 1 - mthiesse@ can't repro this on a Pixel 2, with a ToT build and Chrome Canary. I have no idea what's special about my setup, but, I can't induce the failure with any combination of official builds. I feel like there could be something lurking here, but it may not be worth pursuing. nyquist@, let me know if you want to keep this open, or if we should just close it down.
,
Mar 19 2018
I don't yet understand how this can happen in any case. The package names should be different and in general code should be separate enough so that this doesn't happen. I'm just not sure whether it's something on your end, or whether there's something inherently bad with our code.
,
Mar 21 2018
if it only repro's on a single device with tracing turned on (i.e. not typical user scenario) then moving out to M68 and downgrading Pri to 2. if we do get more consistent repros w/o tracing turned on, we should fix in 66 as P1, but doesn't seem like that now.
,
Mar 23 2018
Folks, I found that my Android OC userdebug build had not updated since December. Whatever train I was on wasn't getting updates. After I updated to the latest Android OC MR1 build, I can no longer repro this issue. I'm going to close this off. Sorry for the noise!
,
Mar 23 2018
Thanks for the update! |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by cjgrant@chromium.org
, Feb 28 2018