Various browser_tests trying (and failing) to create registry keys |
||||
Issue descriptionAs 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.
,
Apr 18 2018
,
Apr 19 2018
Note that this isn't test-specific; this happens in app code: https://codesearch.chromium.org/chromium/src/chrome/installer/util/install_util.cc?rcl=4abe7b0fa63ea44106468ac4e0a5d67c3dd33c22&l=588
,
Apr 20 2018
True. It seems that we still wouldn't want that to surface in the tests --- is that not the case?
,
Apr 20 2018
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?
,
Apr 20 2018
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.
,
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.
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned".
,
Nov 21
***Mass UI Triage*** |
||||
►
Sign in to add a comment |
||||
Comment 1 by jchin...@chromium.org
, Apr 18 2018