New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 673957 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Crashing in test if Chrome never hits foreground

Project Member Reported by romax@chromium.org, Dec 14 2016

Issue description

OS: Android 6.0.1

What steps will reproduce the problem?
(1) build chrome_public_test_apk
(2) Make sure device has a locked screen.
(3) run a Chrome test using out/Default/bin/run_chrome_public_test_apk -vv -f MainActivityWithURLTest*

What is the expected result?
Tests pass.

What happens instead?
Failed tests with 
12-13 16:27:06.533 W/System.err(14318): java.lang.AssertionError
12-13 16:27:06.533 W/System.err(14318):         at org.chromium.chrome.browser.metrics.UmaUtils.getForegroundStartTime(UmaUtils.java:96)
12-13 16:27:06.533 W/System.err(14318):         at org.chromium.chrome.browser.tab.TabWebContentsObserver.didCommitProvisionalLoadForFrame(TabWebContentsObserver$
java:212)
12-13 16:27:06.533 W/System.err(14318):         at org.chromium.content.browser.webcontents.WebContentsObserverProxy.didCommitProvisionalLoadForFrame(WebContents$
bserverProxy.java:186)
12-13 16:27:06.533 W/System.err(14318):         at org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(Native Method)
12-13 16:27:06.533 W/System.err(14318):         at org.chromium.base.SystemMessageHandler.handleMessage(SystemMessageHandler.java:41)
12-13 16:27:06.533 W/System.err(14318):         at android.os.Handler.dispatchMessage(Handler.java:102)
12-13 16:27:06.533 W/System.err(14318):         at android.os.Looper.loop(Looper.java:148)
12-13 16:27:06.533 W/System.err(14318):         at android.app.ActivityThread.main(ActivityThread.java:5417)
12-13 16:27:06.534 W/System.err(14318):         at java.lang.reflect.Method.invoke(Native Method)
12-13 16:27:06.534 W/System.err(14318):         at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
12-13 16:27:06.534 W/System.err(14318):         at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)


Suspect since Chrome never hits foreground, the assert might hit.
 
Status: Assigned (was: Untriaged)

Comment 2 by awdf@chromium.org, Apr 19 2017

Cc: jbudorick@chromium.org
I just repro'd this crash locally when re-enabling & running org.chromium.chrome.browser.notifications.NotificationPlatformBridgeTest#testPermissionDenied with the screen locked (2/2 times - tombstone attached).

+1 for stopping it crashing in this scenario. Can we check if the screen is locked & stop the test run / print a big error message to be more useful?

+cc jbudorick@ as it's the same stack you investigated in https://bugs.chromium.org/p/chromium/issues/detail?id=673098 (also from Dec).

I wonder if this could be the mysterious native crash causing this test to ocassionally flake - crbug.com/707528 . But hopefully our test devices don't occasionally have screenlock on (or do they?)
tombstone.txt
286 KB View Download
both our swarmed and nonswarmed bots provision their devices to keep the screen on and unlocked.

As for detection -- it's not a bad idea, particularly doing so on test failure.
FYI, we might be having a related problem in Issue 711708. Every crash there seems to be hitting the assert in UmaUtils.getForegroundStartTime.
Components: Internals>Metrics

Sign in to add a comment