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

Issue 739458 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

headless: TargetDomain* tests are flakily causing unclean exits

Project Member Reported by ellyjo...@chromium.org, Jul 5 2017

Issue description

These tests seem to cause this problem sometimes on swarming:

*** Swarming tried multiple times to delete the run directory and failed ***
*** Hard failing the task ***

e.g.:

Retrying 1 test (retry #1)
[66/66] TargetDomainDisposeContextFailsIfInUse.RunAsyncTest (154 ms)
SUCCESS: all tests passed.
Failed to delete e:\b\swarm_slave\w\ir (4 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 2 seconds.
Failed to delete e:\b\swarm_slave\w\ir (4 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 4 seconds.
Failed to delete e:\b\swarm_slave\w\ir. The following files remain:
- \\?\e:\b\swarm_slave\w\ir
- \\?\e:\b\swarm_slave\w\ir\out
- \\?\e:\b\swarm_slave\w\ir\out\Release_x64
- \\?\e:\b\swarm_slave\w\ir\out\Release_x64\headless_browsertests.exe
Enumerating processes:
- pid 4424; Handles: 2; Exe: None; Cmd: "e:\b\swarm_slave\w\ir\out\Release_x64\headless_browsertests.exe" --type=renderer --dom-automation --enable-browser-side-navigation --force-color-profile=srgb --ipc-connection-timeout=30 --use-gl=osmesa --use-gpu-in-tests --disable-databases --service-pipe-token=35283A45B6DB376278285943D7ACE5CA --lang=en-US --headless --enable-pinch --device-scale-factor=1 --num-raster-threads=4 --enable-main-frame-before-activation --content-image-texture-target=0,0,3553;0,1,3553;0,2,3553;0,3,3553;0,4,3553;0,5,3553;0,6,3553;0,7,3553;0,8,3553;0,9,3553;0,10,3553;0,11,3553;0,12,3553;0,13,3553;0,14,3553;0,15,3553;0,16,3553;0,17,3553;1,0,3553;1,1,3553;1,2,3553;1,3,3553;1,4,3553;1,5,3553;1,6,3553;1,7,3553;1,8,3553;1,9,3553;1,10,3553;1,11,3553;1,12,3553;1,13,3553;1,14,3553;1,15,3553;1,16,3553;1,17,3553;2,0,3553;2,1,3553;2,2,3553;2,3,3553;2,4,3553;2,5,3553;2,6,3553;2,7,3553;2,8,3553;2,9,3553;2,10,3553;2,11,3553;2,12,3553;2,13,3553;2,14,3553;2,15,3553;2,16,3553;2,17,3553;3,0,3553;3,1,3553;3,2,3553;3,3,3553;3,4,3553;3,5,3553;3,6,3553;3,7,3553;3,8,3553;3,9,3553;3,10,3553;3,11,3553;3,12,3553;3,13,3553;3,14,3553;3,15,3553;3,16,3553;3,17,3553;4,0,3553;4,1,3553;4,2,3553;4,3,3553;4,4,3553;4,5,3553;4,6,3553;4,7,3553;4,8,3553;4,9,3553;4,10,3553;4,11,3553;4,12,3553;4,13,3553;4,14,3553;4,15,3553;4,16,3553;4,17,3553 --service-request-channel-token=35283A45B6DB376278285943D7ACE5CA --renderer-client-id=4 --mojo-platform-channel-handle=1692 /prefetch:1
Terminating 1 processes:
- 4424 killed

In the failing builds I can find, a retry of one of the TargetDomain* tests precedes this step failure. Here are two samples:

https://uberchromegw.corp.google.com/i/chromium.win/builders/Win%207%20Tests%20x64%20%281%29/builds/26153
https://uberchromegw.corp.google.com/i/chromium.win/builders/Win%207%20Tests%20x64%20%281%29/builds/26163

Marking Internals>Headless for triage.
 
 Issue 740425  has been merged into this issue.
Cc: altimin@chromium.org alexclarke@chromium.org
Owner: eseckler@chromium.org
Status: Assigned (was: Untriaged)
Looks like a test crashes, but crashpad doesn't manage to handle the crash correctly:

[ RUN      ] TargetDomainCreateAndDeleteBrowserContextTest.RunAsyncTest
[6340:2948:0705/110949.264:17531782:ERROR:registration_protocol_win.cc(84)] TransactNamedPipe: The pipe has been ended. (0x6D)
[6340:2948:0705/110949.265:17531782:WARNING:resource_bundle.cc(353)] locale_file_path.empty() for locale 
[0705/110949.307:ERROR:registration_protocol_win.cc(56)] CreateFile: The system cannot find the file specified. (0x2)
[0705/110949.307:ERROR:registration_protocol_win.cc(56)] CreateFile: The system cannot find the file specified. (0x2)
[6340:4012:0705/110949.326:17531844:ERROR:crashpad_client_win.cc(130)] crash server failed to launch, self-terminating

This probably leaves a child process hanging somehow.

Anyone know if we should have crashpad enabled for these tests, or if we can disable it?
Project Member

Comment 5 by bugdroid1@chromium.org, Aug 3 2017

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

commit dae3c7dd4d5ac24ebd3396dd149e6574de8a0976
Author: Alex Clarke <alexclarke@chromium.org>
Date: Thu Aug 03 11:32:12 2017

Fix lifetime issues for HeadlessBrowserContext observers.

Bug:  751180 ,  739458 
Change-Id: Iceb120b6ddf94f9e032ad5e22d002a6ab44dbbd5
Reviewed-on: https://chromium-review.googlesource.com/598093
Commit-Queue: Alex Clarke <alexclarke@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491700}
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/lib/browser/headless_browser_context_impl.cc
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/lib/browser/headless_network_delegate.cc
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/lib/browser/headless_network_delegate.h
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/lib/browser/headless_url_request_context_getter.cc
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/lib/browser/headless_url_request_context_getter.h
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/lib/headless_devtools_client_browsertest.cc
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/lib/headless_web_contents_browsertest.cc
[modify] https://crrev.com/dae3c7dd4d5ac24ebd3396dd149e6574de8a0976/headless/public/headless_browser_context.h

Status: Fixed (was: Assigned)
Hopefully that's fixed now, please re-open if there are any problems.

Sign in to add a comment