New issue
Advanced search Search tips

Issue 834111 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Various browser_tests trying (and failing) to create registry keys

Project Member Reported by jchin...@chromium.org, Apr 18 2018

Issue description

As part of build infrastructure migrations, we've been running builds side-by-side on the old Buildbot infrastructure and new LUCI infrastructure. Part of the motivations behind LUCI are to have cleaner bot managing, e.g. not performing bot-specific modifications.

One of the side-by-side builds (https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win%207%20Tests%20x64%20(1)/45) fails on MouseEventsTest.TestOnMouseOut:

[ RUN      ] MouseEventsTest.TestOnMouseOut
[2376:4360:0417/130857.915:ERROR:install_util.cc(589)] Unable to create registry key HKLM\SOFTWARE\Policies\Chromium for reading result=2
[2376:3772:0417/130857.962:WARNING:discovery_network_list_win.cc(195)] Failed to open Wlan client handle: 1062
[2376:4360:0417/130857.962:WARNING:chrome_browser_main_win.cc(630)] Command line too long for RegisterApplicationRestart:  --brave-new-test-launcher --cfi-diag=0 --gtest_also_run_disabled_tests --gtest_filter=MouseEventsTest.TestOnMouseOut --single_process --snapshot-output-dir="e:\b\s\w\iogx4wt7" --test-launcher-bot-mode --test-launcher-output="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir3088_10040\results3088_13195\test_results.xml" --test-launcher-summary-output="e:\b\s\w\iogx4wt7\output.json" --user-data-dir="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir3088_10040\d3088_21026" --disable-offline-auto-reload --no-first-run --no-default-browser-check --enable-logging=stderr --disable-default-apps --wm-window-animations-disabled --disable-component-update --test-type=browser --force-color-profile=srgb --disable-zero-browsers-open-for-tests --ipc-connection-timeout=30 --allow-file-access-from-files --dom-automation --log-gpu-control-list-decisions --disable-backgrounding-occluded-windows --disable-gl-drawing-for-tests --override-use-software-gl-for-tests --force-color-profile=srgb --disable-compositor-ukm-for-tests --enable-features=TestFeatureForBrowserTest1 --disable-features=NetworkPrediction,TestFeatureForBrowserTest2 --flag-switches-begin --flag-switches-end --restore-last-session about:blank
[2376:4360:0417/130858.094:INFO:mouse_events_interactive_uitest.cc(43)] Waiting for title: onload

Some of the failing behavior is known (Issue 419468  #16 , and this test has been flaky for a while and is mostly disabled already); what's new is the attempt (and failure) to create a registry key HKLM\SOFTWARE\Policies\Chromium, which appears to be related to a recent feature (crrev.com/8327d5a7).

Creating a registry key for mouse events tests seems odd. If this behavior is indeed unexpected, that dependency should be removed. If it is expected, then the registry keys need to be rewired, e.g. via virtualizing, such that they're not set directly on the bots.*

Tentatively assigning to rogerta@, and please add/re-componentize as appropriate!

*Note that the difference of registry creation happens on LUCI but not Buildbot. The main difference between the two is that LUCI builds do not change bot state. If Buildbot is attempting --- and succeeding --- to create registry keys, that would explain why the Buildbot builds are green, but which eventually leads to an unmaintainable state, so simply writing the key directly is not an option.
 
Actually, this appears to be happening in Buildbot too, see https://ci.chromium.org/buildbot/chromium.win/Win%207%20Tests%20x64%20(1)/37235, browser_tests PolicyToolUITest.CreatingSessionFiles, and also in green test suites, see LUCI example at https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win%207%20Tests%20x64%20(1)/100 (see browser_tests shard #3 MetricsServiceBrowserTest.OOMRenderers (https://chromium-swarm.appspot.com/task?id=3cf31647840f9810&refresh=10&show_raw=1).
Summary: Various browser_tests trying (and failing) to create registry keys (was: MouseEventsTest.TestOnMouseOut is trying (and failing) to create registry keys)
True. It seems that we still wouldn't want that to surface in the tests --- is that not the case?
Not sure I follow exactly what you mean -- we wouldn't want that code to be exercised in tests, or we wouldn't want that code to actually affect the registry?
Both and neither: setting up registry keys in the app might be WAI which is fine, but if tests are failing with an inability to set registry keys*, that seems to suggest lack of hermeticity, which is bad. (If that impression is mistaken and we don't have to worry about those error messages I'm happy to close this as WontFix.)

*So far I haven't seen any failures rooted in inability to set registry keys, only failures rooted elsewhere that also complained about the former. I also haven't seen any evidence pointing to the case that registry key creation would only surface as an error when triggered by other failures.

Comment 7 by giga...@gmail.com, May 10 2018

Not sure if it's relevant here (as the same error seems to crop up all over the place in various tests but this seems to be the only issue dealing with it in particular) but just to add a datapoint - I'm seeing this same error in the current Canary (.3426.0) on startup on W10, causing an instant crash. Attached a log file if it is of any help.
chrome_debug.log
8.0 KB View Download
Status: Assigned (was: Untriaged)
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
Labels: Hotlist-DesktopUIToolingRequired Hotlist-DesktopUIChecked
***Mass UI Triage***


Sign in to add a comment