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

Issue 756421 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

[WPT import] Importer failed to add the correct baselines for windows

Project Member Reported by foolip@chromium.org, Aug 17 2017

Issue description

https://chromium-review.googlesource.com/c/617948

After having updated the CL and starting CQ, win_chromium_rel_ng still failed on these tests:
external/wpt/credential-management/credentialscontainer-create-basics.https.html
external/wpt/svg/interfaces.html
external/wpt/webrtc/RTCCertificate.html
external/wpt/webrtc/RTCConfiguration-bundlePolicy.html
external/wpt/webrtc/RTCConfiguration-iceServers.html
external/wpt/webrtc/RTCConfiguration-iceTransportPolicy.html
external/wpt/webrtc/RTCConfiguration-rtcpMuxPolicy.html
external/wpt/webrtc/RTCPeerConnection-addTransceiver.html
external/wpt/webrtc/RTCPeerConnection-getDefaultIceServers.html
external/wpt/webrtc/RTCPeerConnection-getStats.html
external/wpt/webrtc/RTCPeerConnection-removeTrack.html
external/wpt/webrtc/RTCRtpSender-replaceTrack.html
external/wpt/webrtc/interfaces.html
 

Comment 1 by foolip@chromium.org, Aug 17 2017

Raphael, on the review you also said you think the TestExpectations change and added baselines are wrong, can you fill in some detail about that? It will occasionally be the right thing to change expectations for files which aren't touched directly, but not in this case?
What a weird import :-) I'm still trying to piece everything together, here's what I have so far:

* First of all, I have no idea why wpt-import decided to mark some tests as [ Crash ]'ing on Android. https://luci-milo.appspot.com/buildbot/tryserver.chromium.android/android_blink_rel/3342 shows everything worked fine, and there are no tests in https://storage.googleapis.com/chromium-layout-test-archives/android_blink_rel/3342/layout-test-results/results.html

* Something external to this import was either messing up the Win7 build or that specific VM. According to https://storage.googleapis.com/chromium-layout-test-archives/win7_blink_rel/3715/layout-test-results/results.html, a lot of tests crashed with a backtrace like this ( bug 739282  maybe?):

  STDERR: 	SkFontMgr::legacyCreateTypeface [0x01BC6360+0]
  STDERR: 	content::EnableRendererLayoutTestMode [0x02E95957+183]
  STDERR: 	content::LayoutTestRenderThreadObserver::LayoutTestRenderThreadObserver [0x017A50E1+111]
  STDERR: 	content::LayoutTestContentRendererClient::RenderThreadStarted [0x017978EF+31]
  STDERR: 	content::RenderThreadImpl::Init [0x02D2B9E8+3278]
  STDERR: 	content::RenderThreadImpl::RenderThreadImpl [0x02D2ABDE+1058]
  STDERR: 	content::RenderThreadImpl::Create [0x02D2A78F+71]
  STDERR: 	content::RendererMain [0x02CFEB3C+460]
  STDERR: 	content::RunNamedProcessTypeMain [0x00CE727F+123]
  STDERR: 	content::ContentMainRunnerImpl::Run [0x00CE7762+162]
  STDERR: 	service_manager::Main [0x02400C70+620]
  STDERR: 	content::ContentMain [0x00CE71AD+49]
  STDERR: 	wWinMain [0x00A51051+81]
  STDERR: 	__scrt_common_main_seh [0x038717B8+246] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253)
  STDERR: 	BaseThreadInitThunk [0x76CC336A+18]
  STDERR: 	RtlInitializeExceptionChain [0x77669902+99]
  STDERR: 	RtlInitializeExceptionChain [0x776698D5+54]

* wpt-import then reported it would mark some http-related WPT tests as crashing on Win7 and Android; like I said, I don't get why Android was added to the list, but the Win7 VM was definitely crashing.

* Given the unrelated crash results from Win7, wpt-import also added new expectations to LayoutTests/platform/win7 since they in theory looked different from what all other trybots reported. And as you can see in Gerrit, the new Win7-specific expectations are basically the old, general -expected.txt files before this import (compare svg/interface-expected.txt, for example).

* I'm assuming the win_chromium_rel_ng bot that was processing the CQ dry-run runs Windows 7. If you look at https://storage.googleapis.com/chromium-layout-test-archives/win_chromium_rel_ng/513963/layout-test-results/results.html, all the reported layout test failures are due to the fact that the expectations were wrong. In fact, they're the ones from LayoutTests/platform/win7!
1. The reason why tests were marked as a Crashing on Android is because there's a rule now in wpt-update-expectations that for new expectations, any platforms where the test is skipped are also added to the list of specifiers. This makes sense when there are cross-platform expectations, e.g. a test crashes on most/all other platforms besides Android and the test is skipped on Android, so we add Android to the list of platforms because it would probably crash too. This is the same issue as  bug 750684 .

4. You're correct that win_chromium_rel_ng runs Windows 7; this can be seen by looking at the details for the VMs on 
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng.

Comment 4 by foolip@chromium.org, Aug 17 2017

https://chromium-review.googlesource.com/c/619152 is what the manual import ended up looking like, and the most interesting difference is that I didn't add any win7-specific baselines.

In https://chromium-review.googlesource.com/c/617948/1 the win7_blink_rel job was purple and I see "TEST RESULTS WERE INVALID" in the build summary view. Could that have anything to do with it?
> In https://chromium-review.googlesource.com/c/617948/1 the win7_blink_rel job was purple and I see "TEST RESULTS WERE INVALID" in the build summary view. Could that have anything to do with it?

Yes. Like I said, the crashes caused by something external to the import then led wpt-import to mark some tests as crashing and create a platform/win7 because the results differed from the ones generated by the other bots.
I believe that this was a failure caused by a temporary Windows bot issue, and not something that will consistently cause problems in the future.

Are there any follow-up next actions here? If not, shall we close this issue?
The only possible action I can think is either ignoring or restarting purple jobs, but we can track that separately. I think this issue can be closed.
Status: WontFix (was: Untriaged)

Sign in to add a comment