Looks like things are much better now. I'm guessing https://codereview.chromium.org/2004423007 fixed this.

Looks like that fixed most, but some redness is still around:

Widevine tests fail on 64-bit official (and maybe 32-bit official; that bot failed compile for a while, but a fix for that is in the cq)

https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3335

The widevine failures started at https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3330 and are very likely due to  https://codereview.chromium.org/1996863002 -- xhwang, I'm guessing browser_tests are now broken in official builds on Windows (independent of clang).

I failed to reproduce these failures in local official builds, with both cl.exe and clang-cl. The bots do clobber builds, but I didn't, so it's possible some file that got moved around is still around in my local checkout but not on the bot.

I removed the output folder out/Release/WidevineCdm before building. This folder is really what matters for this failure. I couldn't repro the failures as well.

Pasting some error stacks:

MSE_Widevine/EncryptedMediaTest.Playback_AudioClearVideo_WebM/0 (run #1):
[ RUN      ] MSE_Widevine/EncryptedMediaTest.Playback_AudioClearVideo_WebM/0
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.799 -  Using WidevinePlayer", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.801 -  Registering video event handlers.", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.802 -  Setting video media keys: com.widevine.alpha", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(145)] "FAIL: NotSupportedError Unsupported keySystem", source: http://127.0.0.1:55393/eme_player_js/utils.js (145)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.809 -  Set document title to: NOTSUPPORTEDERROR, updated title: NOTSUPPORTEDERROR", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.810 -  Loading media using MSE.", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.811 -  video.src has been set to blob:http://127.0.0.1:55393/bc5b8bf1-3670-4100-95a9-cd428d67d67e", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.811 -  initEMEPlayer() done", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.812 -  Media player created.", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
[444:4296:0526/145503:INFO:CONSOLE(277)] "14:55:03.813 -  Starting play, hidden: false", source: http://127.0.0.1:55393/eme_player_js/utils.js (277)
..\..\chromerowser\media\media_browsertest.cc(53): error: Value of: final_title
  Actual: "NOTSUPPORTEDERROR"
Expected: expected_title
Which is: "EME_UPDATE_FAILED"
[444:4296:0526/145503:INFO:CONSOLE(2



EncryptedMediaSupportedTypesWidevineTest.Audio_MP4 (run #1):
[ RUN      ] EncryptedMediaSupportedTypesWidevineTest.Audio_MP4
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(634): error: Value of: AreCodecsSupportedByKeySystem( kAudioMP4MimeType, audio_mp4_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kSuccessResult
Which is: "success"
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(638): error: Value of: AreCodecsSupportedByKeySystem( kAudioMP4MimeType, video_mp4_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kNoMatchResult
Which is: "None of the requested configurations were supported."

Thanks!

These basically say that the Widevine CDM isn't registered properly. There are multiple possible cases that could cause this:

1. The Widevine CDM files are not available in the correct location, in this case, they should be at
  out\Release_x64\WidevineCdm\manifest.json
  out\Release_x64\WidevineCdm\_platform_specific\win_x64\widevinecdm.dll
  out\Release_x64\WidevineCdm\_platform_specific\win_x64\widevinecdmadapter.dll

I do see logs that these files are in place:
https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3335/steps/extract%20build/logs/stdio

2. Component updater isn't enabled in the tests (e.g. --disable-component-updater is used). My CL should have removed this flag in those tests. I tested this on Mac and Windows and confirmed that this flag is indeed removed.

At this moment I am running out of ideas. Not being able to repro this locally definitely makes it trickier. I'll see what I can add to help investigate this issue.

I prepared https://chromiumcodereview.appspot.com/2020573002/ to help collect more info about the failure.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/30a18d08f62378cbd8f8c6df83ec5ca1fb548a32

commit 30a18d08f62378cbd8f8c6df83ec5ca1fb548a32
Author: xhwang <xhwang@chromium.org>
Date: Fri May 27 12:29:38 2016

media: Check Widevine CDM registration and availability.

This will also help investigate root cause of  issue 614745 .

BUG= 614745 

Review-Url: https://codereview.chromium.org/2020573002
Cr-Commit-Position: refs/heads/master@{#396446}

[modify] https://crrev.com/30a18d08f62378cbd8f8c6df83ec5ca1fb548a32/chrome/browser/content_settings/content_settings_browsertest.cc
[modify] https://crrev.com/30a18d08f62378cbd8f8c6df83ec5ca1fb548a32/chrome/browser/media/pepper_cdm_test_helper.cc
[modify] https://crrev.com/30a18d08f62378cbd8f8c6df83ec5ca1fb548a32/chrome/browser/media/pepper_cdm_test_helper.h

It seems the CDM is there but it's not registered as a plugin yet. It could be timing related. Checking where I can add more checks/logs to help investigate this.

PepperContentSettingsSpecialCasesJavaScriptBlockedTest.WidevineCdm (run #1):
[ RUN      ] PepperContentSettingsSpecialCasesJavaScriptBlockedTest.WidevineCdm
...
..\..\chromerowser\content_settings\content_settings_browsertest.cc(512): error: Value of: IsPepperCdmRegistered(kWidevineCdmPluginMimeType)
  Actual: false
Expected: true

I can repro the failure on Linux* by adding a 2-second delay in WidevineCdmComponentInstallerTraits::UpdateCdmAdapter(). This function runs on the blocking pool so the all the content::RunAllPendingInMessageLoop() calls in InProcessBrowserTest::RunTestOnMainThreadLoop() won't wait for UpdateCdmAdapter() to finish. Therefore in theory we could start to run the test without the Widevine CDM being properly registered.

That being said, even adding 1 second delay won't cause the test to fail on my Linux machine. So I suspect we could be dealing with a different issue on this Windows Clang bot.

I'll add some more LOG(INFO) to check whether this hypothesis is correct. If so, I'll revert my offending CL and we can discuss what we can do.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/324623c7cf1ccb0a674a31fe15b3bf996f8f3f3a

commit 324623c7cf1ccb0a674a31fe15b3bf996f8f3f3a
Author: xhwang <xhwang@chromium.org>
Date: Fri May 27 21:47:49 2016

Add logging in WidevineCdmComponentInstaller to help investigate a bug.

These logs will be removed after the investigation is finished.

BUG= 614745 

Review-Url: https://codereview.chromium.org/2013403003
Cr-Commit-Position: refs/heads/master@{#396570}

[modify] https://crrev.com/324623c7cf1ccb0a674a31fe15b3bf996f8f3f3a/chrome/browser/component_updater/widevine_cdm_component_installer.cc

[ RUN      ] MSE_Widevine/EncryptedMediaTest.Playback_AudioOnly_WebM_Opus/0
Some features may not be available.
[988:4376:0531/090038:WARNING:widevine_cdm_component_installer.cc(324)] GetRelativeInstallDir
[988:4376:0531/090038:WARNING:widevine_cdm_component_installer.cc(324)] GetRelativeInstallDir
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.725 -  Using WidevinePlayer", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.727 -  Registering video event handlers.", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.727 -  Setting video media keys: com.widevine.alpha", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(145)] "FAIL: NotSupportedError Unsupported keySystem", source: http://127.0.0.1:50865/eme_player_js/utils.js (145)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.732 -  Set document title to: NOTSUPPORTEDERROR, updated title: NOTSUPPORTEDERROR", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.732 -  Loading media using MSE.", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.733 -  video.src has been set to blob:http://127.0.0.1:50865/bd59d748-b39a-4bd9-ba1e-32f6513125c7", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.733 -  initEMEPlayer() done", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.733 -  Media player created.", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.734 -  Starting play, hidden: false", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
..\..\chromerowser\media\media_browsertest.cc(53): error: Value of: final_title
  Actual: "NOTSUPPORTEDERROR"
Expected: expected_title
Which is: "EME_UPDATE_FAILED"
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.783 -  Event: play", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
[988:3336:0531/090038:INFO:CONSOLE(277)] "09:00:38.783 -  Event: waiting", source: http://127.0.0.1:50865/eme_player_js/utils.js (277)
..\..\chromerowser\media\encrypted_media_browsertest.cc(181): error: Value of: receivedKeyMessage
  Actual: false
Expected: true
[  FAILED  ] MSE_Widevine/EncryptedMediaTest.Playback_AudioOnly_WebM_Opus/0, where GetParam() = (0547B2F5 pointing to "com.widevine.alpha", 1) (613 ms)


[ RUN      ] EncryptedMediaSupportedTypesWidevineTest.Video_MP4
Some features may not be available.
[1756:2980:0531/085916:WARNING:widevine_cdm_component_installer.cc(324)] GetRelativeInstallDir
[1756:2980:0531/085916:WARNING:widevine_cdm_component_installer.cc(324)] GetRelativeInstallDir
[1756:4760:0531/085917:INFO:CONSOLE(50)] "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play.", source: http://127.0.0.1:63400/test_key_system_instantiation.html (50)
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(612): error: Value of: AreCodecsSupportedByKeySystem( kVideoMP4MimeType, video_mp4_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kSuccessResult
Which is: "success"
[1756:4760:0531/085917:INFO:CONSOLE(50)] "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play.", source: http://127.0.0.1:63400/test_key_system_instantiation.html (50)
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(616): error: Value of: AreCodecsSupportedByKeySystem( kVideoMP4MimeType, video_mp4_hi10p_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kNoMatchResult
Which is: "None of the requested configurations were supported."
[1756:4760:0531/085917:INFO:CONSOLE(50)] "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play.", source: http://127.0.0.1:63400/test_key_system_instantiation.html (50)
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(620): error: Value of: AreCodecsSupportedByKeySystem( kVideoMP4MimeType, audio_mp4_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kNoMatchResult
Which is: "None of the requested configurations were supported."
[1756:4760:0531/085917:INFO:CONSOLE(50)] "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play.", source: http://127.0.0.1:63400/test_key_system_instantiation.html (50)
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(624): error: Value of: AreCodecsSupportedByKeySystem( kVideoMP4MimeType, invalid_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kNoMatchResult
Which is: "None of the requested configurations were supported."
[1756:4760:0531/085917:INFO:CONSOLE(50)] "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play.", source: http://127.0.0.1:63400/test_key_system_instantiation.html (50)
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(626): error: Value of: AreCodecsSupportedByKeySystem( kVideoMP4MimeType, audio_webm_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kNoMatchResult
Which is: "None of the requested configurations were supported."
[1756:4760:0531/085917:INFO:CONSOLE(50)] "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play.", source: http://127.0.0.1:63400/test_key_system_instantiation.html (50)
..\..\chromerowser\media\encrypted_media_supported_types_browsertest.cc(628): error: Value of: AreCodecsSupportedByKeySystem( kVideoMP4MimeType, video_webm_codecs(), kWidevine)
  Actual: "Unsupported keySystem"
Expected: kNoMatchResult
Which is: "None of the requested configurations were supported."
[  FAILED  ] EncryptedMediaSupportedTypesWidevineTest.Video_MP4, where TypeParam =  and GetParam() =  (648 ms)



Looks like GetRelativeInstallDir() is called but nothing else.

Thanks. Unfortunately it seems there could still be multiple reasons to cause this:
1) Blocking pool delay as suspected in #10.
2) DefaultComponentInstaller failed to install the "preinstalled" CDM for some reason.

Both cases seem unlikely to me. For (1), I don't see how the blocking pool can be delayed for so long. For (2), I don't see how this only happens on this bot. But I can be totally wrong :(

I'll have to enable more logs to see what's happening. Sorry for breaking this bot for so long.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ade0ad062792a4e27ab295638379f419bdf10eff

commit ade0ad062792a4e27ab295638379f419bdf10eff
Author: xhwang <xhwang@chromium.org>
Date: Wed Jun 01 01:51:51 2016

Add logging in DefaultComponentInstaller to help investigate a bug

Now we know that GetRelativeInstallDir() is called for Widevine CDM but
we never see ComponentReady() to be called. Adding logs for all failure
cases to see what is going wrong.

Another possibility is that FinishRegistration() doesn't have a chance
to run before the test starts. In that case we'll see
StartRegistration() but won't see FinishRegistration().

BUG= 614745 

Review-Url: https://codereview.chromium.org/2022273002
Cr-Commit-Position: refs/heads/master@{#397021}

[modify] https://crrev.com/ade0ad062792a4e27ab295638379f419bdf10eff/components/component_updater/default_component_installer.cc

New logs are available now, e.g.:

https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3362/steps/browser_tests%20on%20Windows-7-SP1/logs/PepperContentSettingsSpecialCasesJavaScriptBlockedTest.WidevineCdm

First, FinishRegistration() is called for Widevine CDM, so the hypothesis in #10 is wrong.

However, it's super weird that we are not getting any logs in FindPreinstallation(), even though we are pretty sure that it's called. I added LOG(WARNING) for every possible return statement in this function. But I don't see any of them in the log. I don't really understand how this could be possible.

FWIW, I tried the latest CL on Linux (with some local change to trigger this path) and I do get the logs in FindPreinstallation(), e.g.

[29738:29801:0531/215549:WARNING:default_component_installer.cc(197)] Preinstalled component found for Widevine Content Decryption Module at <...>/src/out/GN/WidevineCdm with version 1.4.8.893.

The bot runs browser_tests on swarming while you probably run them locally. Maybe some required file isn't uploaded to the swarming bots?

See #6. The test files should be there (as specified in browser_tests.isolate).

Now the problem is why the new LOG(WARNING)s I added in FindPreinstallation() doesn't show up in the log, while other LOG(WARNING)s I added all show up without any problem.

okay, the log does appear in the raw logs (stdio):

https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3362/steps/browser_tests%20on%20Windows-7-SP1/logs/stdio

So the error is:

[8292:8852:0531/203805:WARNING:default_component_installer.cc(175)] Manifest does not exist: e:\b\swarm_slave\work\isolated\runt2raat\out\Release_x64\WidevineCdm

Now I see what the problem is. In browser_tests.isolate I forgot to include the manifest file. So this is a real bug and I'll fix it.

I guess I had some misunderstanding about what the "extract build" step is:

https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3335/steps/extract%20build/logs/stdio

I thought that's extracting files to be used on swarming, but apparently I was wrong.

I'll upload a fix shortly. Thank you all for the help and patience!

No, extract_build is a part of the very old builder/tester setup where one bot builds everything (the builder) and a second bot runs the test (the tester). extract_build extracts the zip made by the builder and extracts it. Nowadays, the tester runs most tests on swarming, so it zips bits and pieces up again and sends them to swarming.

Good to hear that a fix is coming up :-)

So is there a way to check what's being zipped and sent to swarming? That'd be very helpful in investigating bugs like this.

There is, but I always forget how to do it. It's also a bit different with gyp and gn..

With gyp, I think you can build the _run target corresponding to your test binary (e.g. base_unittests_run) and then look at the .isolated file (out/Release/base_unittests.isolated), which iirc will contain a list of files that will be zipped up.

With gn, you can run something like `gn desc out/gnwin //base:base_unittests runtime_deps` to see what files gn thinks should be zipped up. The isolate file is written by "mb" on the bots, and you can ask mb to run tests through swarming locally like so: If you have a GN build directory in out/gn, you can run `python tools\mb\mb.py run //out/gn base_unittests`

It also used to be possible to download isolate zips from the swarming server by clicking the "shard #N isolate out" link on a buildbot build page, but it looks like the UI has changed and I can't see that any more.

aha: Click "shard #N" at the trigger step, then you'll get something like https://chromium-swarm.appspot.com/user/task/2f0608c1b5c98810 (sign in with your @google) which lists commands like so:

Download inputs files into directory foo:
  python isolateserver.py download -I https://isolateserver.appspot.com --namespace default-gzip -s 39c639935f629cf4dc7819ccfac7ab5162f596c9 --target foo

Run this task locally:
  python swarming.py reproduce -S https://chromium-swarm.appspot.com 2f0608c1b5c98810

Download output results into directory foo:
  python swarming.py collect -S https://chromium-swarm.appspot.com --task-output-dir=foo 2f0608c1b5c98810

Looking for swarming.py?
  git clone https://github.com/luci/client-py

Thanks!!!

I think I actually tried this when I was working on the original CL. But I totally forgot I can do this when investigating this bug. This would've made my life way easier. Lesson learned.

BTW, it's still a mystery why some log is in the raw stdio log but not in the log for the test.

Raw stdio:

https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3362/steps/browser_tests%20on%20Windows-7-SP1/logs/stdio

Log for the test:

https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3362/steps/browser_tests%20on%20Windows-7-SP1/logs/PepperContentSettingsSpecialCasesJavaScriptBlockedTest.WidevineCdm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/850d4ae72d7f0dcd54b6b699447412f5f99ec4b2

commit 850d4ae72d7f0dcd54b6b699447412f5f99ec4b2
Author: xhwang <xhwang@chromium.org>
Date: Wed Jun 01 18:57:33 2016

media: Add Widevine CDM manifest.json in browser_tests.isolate

This is required to run the browser_tests on swarming.

BUG= 614745 ,582622
TEST=This fixes failing browser_tests.

Review-Url: https://codereview.chromium.org/2028133002
Cr-Commit-Position: refs/heads/master@{#397197}

[modify] https://crrev.com/850d4ae72d7f0dcd54b6b699447412f5f99ec4b2/chrome/browser_tests.isolate

The bot is green now (phew!): 

https://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%20tester/builds/3371

I'll mark this issue as fixed. At the same time I'll send out a CL clearing the LOG(WARNING)s I added.

It's still broken on gn bots, right? (these bots just aren't on gn yet)

I would've kept this open until your gn fix landed too :-)

Fair enough :) Reopened to track the GN change and log cleaning.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f82503faa7ebe8efa43903908fda396ea8f40b9

commit 0f82503faa7ebe8efa43903908fda396ea8f40b9
Author: xhwang <xhwang@chromium.org>
Date: Thu Jun 02 07:02:21 2016

media: Mark Widevine CDM and manifest as data_deps of the adapter

The CDM is needed by the adapter at link time and at run time. The
manifest.json file is only required at run time. To make it always
available at run time (e.g. for isolated tests), we should mark them
as data_deps.

Note that shared libraries are automatically treated as runtime_deps.
Therefore, we don't need to do this for clearkeycdm.

There are two cases that's worth noting but I am not treating them
separately for the sake of simplicity:
1. In theory, we don't need this for the stub CDM because it's also
   a shared library.
2. On Windows, this will list widevinecdm.dll.lib as runtime_deps
   which isn't necessary.

BUG= 614745 
TEST=This should fix isolated browser_tests on official GN bots.

Review-Url: https://codereview.chromium.org/2027373002
Cr-Commit-Position: refs/heads/master@{#397324}

[modify] https://crrev.com/0f82503faa7ebe8efa43903908fda396ea8f40b9/third_party/widevine/cdm/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c4f2d5df530b9e1139af40df5ba53bdca5502e7c

commit c4f2d5df530b9e1139af40df5ba53bdca5502e7c
Author: xhwang <xhwang@chromium.org>
Date: Thu Jun 02 22:11:45 2016

Clear logging in Widevine CDM and default component installer

The bug has been fixed. Conventing LOG(WARNING)s into DLOG(WARNING)s.

BUG= 614745 
TEST=No functionality change.

Review-Url: https://codereview.chromium.org/2036583002
Cr-Commit-Position: refs/heads/master@{#397527}

[modify] https://crrev.com/c4f2d5df530b9e1139af40df5ba53bdca5502e7c/chrome/browser/component_updater/widevine_cdm_component_installer.cc
[modify] https://crrev.com/c4f2d5df530b9e1139af40df5ba53bdca5502e7c/components/component_updater/default_component_installer.cc

GN is fixed and logs cleared. Mark this as fixed now.