New issue
Advanced search Search tips

Issue 848398 link

Starred by 4 users
Status: Archived
Owner:
alph@chromium.org
Closed: Dec 5
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

"http/tests/devtools/oopif/oopif-performance-cpu-profiles.js" is flaky

Project Member Reported by chromium...@appspot.gserviceaccount.com, May 31 2018 
"http/tests/devtools/oopif/oopif-performance-cpu-profiles.js" is flaky.

This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label.

We have detected 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyRgsSBUZsYWtlIjtodHRwL3Rlc3RzL2RldnRvb2xzL29vcGlmL29vcGlmLXBlcmZvcm1hbmNlLWNwdS1wcm9maWxlcy5qcww.

Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs

Comment 1 by kpaulhamus@chromium.org, May 31 2018

Labels: -Sheriff-Chromium
Owner: alph@chromium.org
Status: Assigned (was: Untriaged)
This test appears to be consistently timing out.
Project Member

Comment 2 by bugdroid1@chromium.org, May 31 2018 

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

commit dbf25685580ee9cb53c807ef84b25b114daf093d
Author: Alexei Filippov <alph@chromium.org>
Date: Thu May 31 22:29:19 2018

Mark http/tests/devtools/oopif/oopif-performance-cpu-profiles.js as flaky

NOTRY=true
TBR=kpaulhamus@chromium.org
BUG= 848398 

Change-Id: I6d769cc2fd3d9bc393b6320387fc7a43a630473a
Reviewed-on: https://chromium-review.googlesource.com/1081493
Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563403}
[modify] https://crrev.com/dbf25685580ee9cb53c807ef84b25b114daf093d/third_party/WebKit/LayoutTests/TestExpectations
Project Member

Comment 3 by chromium...@appspot.gserviceaccount.com, Jun 9 2018

Labels: Sheriff-Chromium
Detected 5 new flakes for test/step "http/tests/devtools/oopif/oopif-performance-cpu-profiles.js". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyRgsSBUZsYWtlIjtodHRwL3Rlc3RzL2RldnRvb2xzL29vcGlmL29vcGlmLXBlcmZvcm1hbmNlLWNwdS1wcm9maWxlcy5qcww. This message was posted automatically by the chromium-try-flakes app. Since flakiness is ongoing, the issue was moved back into Sheriff Bug Queue (unless already there).
Project Member

Comment 4 by bugdroid1@chromium.org, Jun 11 2018 

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

commit b8771c718b64645ac4e32a22d696c826d7e921c6
Author: Hayato Ito <hayato@chromium.org>
Date: Mon Jun 11 08:02:19 2018

Mark http/tests/devtools/oopif/oopif-performance-cpu-profiles.js as flaky on all platforms

NOTRY=true
TBR=alph@chromium.org
BUG= 848398 

Change-Id: Ib35a8b041f31aa55597f9711d72f9368cd213010
Reviewed-on: https://chromium-review.googlesource.com/1095055
Reviewed-by: Hayato Ito <hayato@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565944}
[modify] https://crrev.com/b8771c718b64645ac4e32a22d696c826d7e921c6/third_party/WebKit/LayoutTests/TestExpectations

Comment 5 by tschumann@google.com, Jun 11 2018

Labels: -Sheriff-Chromium

Comment 6 by arthurso...@chromium.org, Jun 11 2018 

FYI: Output when the test fails:

~~~[actual]~~~
Test CPU profiles are recorded for OOPIFs.

name: CrRendererMain
url: http://devtools.oopif.test:8000/devtools/oopif/resources/inner-iframe.html?second
has CpuProfile: true

name: CrRendererMain
url: http://127.0.0.1:8000/devtools/oopif/resources/page.html
has CpuProfile: true


~~~~~~

~~~[expected]~~~
Test CPU profiles are recorded for OOPIFs.

name: CrRendererMain
url: http://127.0.0.1:8000/devtools/oopif/resources/page.html
has CpuProfile: true

name: CrRendererMain
url: http://devtools.oopif.test:8000/devtools/oopif/resources/inner-iframe.html?second
has CpuProfile: true


~~~~~~

So the two entries are interverted. This is a bit weird, because the array is sorted:
~~~[oopif-performance-cpu-profiles.js]~~~

  for (const track of PerformanceTestRunner.timelineModel().tracks().sort((a, b) => a.url > b.url)) {
    if (track.type !== TimelineModel.TimelineModel.TrackType.MainThread)
      continue;
    TestRunner.addResult(`name: ${track.name}`);
    TestRunner.addResult(`url: ${track.url}`);
    TestRunner.addResult(`has CpuProfile: ${track.thread.events().some(e => e.name === 'CpuProfile')}\n`);
  }

~~~~~~

Comment 7 by alph@chromium.org, Jun 11 2018 

Oops, thanks. The last one is easy to fix.
Project Member

Comment 8 by bugdroid1@chromium.org, Jun 13 2018 

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

commit d60729219a5faf0a2075d86d6158df4f0420d994
Author: Alexei Filippov <alph@chromium.org>
Date: Wed Jun 13 21:52:07 2018

Fix http/tests/devtools/oopif/oopif-performance-cpu-profiles.js" is flaky

Make it sorted for real. Fixes one source of flakiness.

BUG= 848398 

Change-Id: I14e40f509e6363e06eeb5ed21bc239b59269bff8
Reviewed-on: https://chromium-review.googlesource.com/1095479
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567005}
[modify] https://crrev.com/d60729219a5faf0a2075d86d6158df4f0420d994/third_party/WebKit/LayoutTests/http/tests/devtools/oopif/oopif-performance-cpu-profiles.js

Comment 9 by martiniss@chromium.org, Jun 21 2018 

FYI this test flaked on me in the CQ in https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win7_chromium_rel_ng/21046. 

Looks like it's crashing now? Should I file another bug? I found this bug via monorail search.

Comment 10 by martiniss@chromium.org, Jun 21 2018 

Flaked in https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win7_chromium_rel_ng/21766 as well (not complete yet, but it did fail)

Comment 11 by kbr@chromium.org, Jun 22 2018

Components: Platform>DevTools>Performance
Labels: OS-Windows
Example crash:
https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win7_chromium_rel_ng/22000

https://chromium-swarm.appspot.com/task?id=3e3d5bc63d6d2a10&refresh=10&show_raw=1

16:09:33.218 3448 worker/0 http/tests/devtools/oopif/oopif-performance-cpu-profiles.js crashed, (stderr lines):
16:09:33.218 3448   [2080:2376:0621/160932.791:FATAL:process_win.cc(120)] Check failed: IsValid(). 
16:09:33.218 3448   Backtrace:
16:09:33.218 3448   	base::debug::StackTrace::StackTrace [0x02DAE220+32]
16:09:33.218 3448   	base::debug::StackTrace::StackTrace [0x02DAD9DD+13]
16:09:33.218 3448   	logging::LogMessage::~LogMessage [0x02DC62D3+83]
16:09:33.218 3448   	base::Process::Pid [0x02DE9CCB+91]
16:09:33.218 3448   	content::protocol::TracingHandler::RecordClockSyncMarker [0x01DF23A1+631]
16:09:33.218 3448   	content::protocol::TracingHandler::ReadyToCommitNavigation [0x01DF24C6+76]
16:09:33.218 3448   	content::RenderFrameDevToolsAgentHost::ReadyToCommitNavigation [0x01DF51BB+61]
16:09:33.218 3448   	content::WebContentsImpl::ReadyToCommitNavigation [0x020DC5D5+127]
16:09:33.218 3448   	content::NavigationHandleImpl::ReadyToCommitNavigation [0x01E66AC0+2898]
16:09:33.218 3448   	content::NavigationHandleImpl::WillProcessResponse [0x01E630B9+359]
16:09:33.218 3448   	content::NavigationRequest::OnResponseStarted [0x01E6AF71+1549]
16:09:33.218 3448   	content::NavigationURLLoaderImpl::OnReceiveResponse [0x01F16051+183]
1


Please disable this test until it's fixed. It's blocking the commit queue and causing expensive retries.

Comment 13 by alph@chromium.org, Jun 25 2018

Labels: -Pri-1 Pri-2
There is another crash stack trace. We seem to have several sources of flakiness:

crash log for unknown process name (pid <unknown>):
STDOUT: <empty>
STDERR: OUTPUT CONTAINS "AddressSanitizer", so we are treating this test as if it crashed, even though it did not.
STDERR: 
STDERR: =================================================================
STDERR: ==1==ERROR: AddressSanitizer: use-after-poison on address 0x7ef2da82b400 at pc 0x0000096abc5c bp 0x7fff5e9c1710 sp 0x7fff5e9c1708
STDERR: READ of size 8 at 0x7ef2da82b400 thread T0 (content_shell)
STDERR:     #0 0x96abc5b in Invoke<void (base::trace_event::TraceLog::AsyncEnabledStateObserver::*)(), base::WeakPtr<base::trace_event::TraceLog::AsyncEnabledStateObserver>> ./../../base/bind_internal.h:507:12
STDERR:     #1 0x96abc5b in MakeItSo<void (base::trace_event::TraceLog::AsyncEnabledStateObserver::*)(), base::WeakPtr<base::trace_event::TraceLog::AsyncEnabledStateObserver>> ./../../base/bind_internal.h:627:0
STDERR:     #2 0x96abc5b in RunImpl<void (base::trace_event::TraceLog::AsyncEnabledStateObserver::*)(), std::__1::tuple<base::WeakPtr<base::trace_event::TraceLog::AsyncEnabledStateObserver> >, 0> ./../../base/bind_internal.h:681:0
STDERR:     #3 0x96abc5b in base::internal::Invoker<base::internal::BindState<void (base::trace_event::TraceLog::AsyncEnabledStateObserver::*)(), base::WeakPtr<base::trace_event::TraceLog::AsyncEnabledStateObserver> >, void ()>::RunOnce(base::internal::BindStateBase*) ./../../base/bind_internal.h:649:0
STDERR:     #4 0x95183f3 in Run ./../../base/callback.h:99:12
STDERR:     #5 0x95183f3 in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./../../base/debug/task_annotator.cc:101:0
STDERR:     #6 0x70de825 in base::sequence_manager::internal::ThreadControllerImpl::DoWork(base::sequence_manager::internal::ThreadControllerImpl::WorkType) ./../../third_party/blink/renderer/platform/scheduler/base/thread_controller_impl.cc:166:21
STDERR:     #7 0x95183f3 in Run ./../../base/callback.h:99:12
STDERR:     #8 0x95183f3 in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./../../base/debug/task_annotator.cc:101:0
STDERR:     #9 0x95747c5 in base::MessageLoop::RunTask(base::PendingTask*) ./../../base/message_loop/message_loop.cc:319:25
STDERR:     #10 0x9575a34 in DeferOrRunPendingTask ./../../base/message_loop/message_loop.cc:329:5
STDERR:     #11 0x9575a34 in base::MessageLoop::DoWork() ./../../base/message_loop/message_loop.cc:373:0
STDERR:     #12 0x957de0f in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ./../../base/message_loop/message_pump_default.cc:37:31
STDERR:     #13 0x95d6e21 in base::RunLoop::Run() ./../../base/run_loop.cc:102:14
STDERR:     #14 0x1400d599 in content::RendererMain(content::MainFunctionParams const&) ./../../content/renderer/renderer_main.cc:218:23
STDERR:     #15 0x7499519 in content::RunZygote(content::ContentMainDelegate*) ./../../content/app/content_main_runner_impl.cc:561:14
STDERR:     #16 0x749cd01 in content::ContentMainRunnerImpl::Run() ./../../content/app/content_main_runner_impl.cc:960:10
STDERR:     #17 0xd657e33 in service_manager::Main(service_manager::MainParams const&) ./../../services/service_manager/embedder/main.cc:459:29
STDERR:     #18 0x52cc7b0 in content::ContentMain(content::ContentMainParams const&) ./../../content/app/content_main.cc:19:10
STDERR:     #19 0x32f0f3b in main ./../../content/shell/app/shell_main.cc:39:10
STDERR:     #20 0x7fcd5fc54f44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287:0
STDERR: 
STDERR: Address 0x7ef2da82b400 is a wild pointer.
STDERR: SUMMARY: AddressSanitizer: use-after-poison (/b/s/w/ir/out/Release/content_shell+0x96abc5b)
STDERR: Shadow bytes around the buggy address:
STDERR:   0x0fdedb4fd630: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd640: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd650: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd660: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd670: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR: =>0x0fdedb4fd680:[f7]f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd690: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd6a0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd6b0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd6c0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR:   0x0fdedb4fd6d0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
STDERR: Shadow byte legend (one shadow byte represents 8 application bytes):
STDERR:   Addressable:           00
STDERR:   Partially addressable: 01 02 03 04 05 06 07
STDERR:   Heap left redzone:       fa
STDERR:   Freed heap region:       fd
STDERR:   Stack left redzone:      f1
STDERR:   Stack mid redzone:       f2
STDERR:   Stack right redzone:     f3
STDERR:   Stack after return:      f5
STDERR:   Stack use after scope:   f8
STDERR:   Global redzone:          f9
STDERR:   Global init order:       f6
STDERR:   Poisoned by user:        f7
STDERR:   Container overflow:      fc
STDERR:   Array cookie:            ac
STDERR:   Intra object redzone:    bb
STDERR:   ASan internal:           fe
STDERR:   Left alloca redzone:     ca
STDERR:   Right alloca redzone:    cb
STDERR:   Shadow gap:              cc
STDERR: [25483:25580:0625/103925.821656:WARNING:crash_handler_host_linux.cc(334)] Could not translate tid, attempt = 1 retry ...
STDERR: [25483:25580:0625/103925.924731:WARNING:crash_handler_host_linux.cc(334)] Could not translate tid, attempt = 2 retry ...
STDERR: ==1==ABORTING
Project Member

Comment 14 by bugdroid1@chromium.org, Jun 26 2018 

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

commit 98818706622f81e6548bcafe6a772579e561e851
Author: Alexei Filippov <alph@chromium.org>
Date: Tue Jun 26 00:26:29 2018

DevTools: Do not call base::Process::Pid on invalid handles

The function makes a DCHECK(IsValid()) thus causing it to crash in debug.

BUG= 848398 

Change-Id: I3af4495edeffff652507637e914da61dac5c5476
Reviewed-on: https://chromium-review.googlesource.com/1114182
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570262}
[modify] https://crrev.com/98818706622f81e6548bcafe6a772579e561e851/content/browser/devtools/protocol/tracing_handler.cc

Comment 15 by majidvp@chromium.org, Jul 4 

FWIW, here is another flakiness case I am seeing on my CL:

[1] https://test-results.appspot.com/data/layout_results/win7_chromium_rel_ng/30638/layout-test-results/results.html

The stack trace is different from the above:


STDERR: [3716:1048:0703/155949.053:FATAL:process_win.cc(120)] Check failed: IsValid(). 
STDERR: Backtrace:
STDERR: 	base::debug::StackTrace::StackTrace [0x01AA4E80+32]
STDERR: 	base::debug::StackTrace::StackTrace [0x01AA463D+13]
STDERR: 	logging::LogMessage::~LogMessage [0x01ABCDF3+83]
STDERR: 	base::Process::Pid [0x01AE07EB+91]
STDERR: 	content::protocol::TracingHandler::SetupProcessFilter [0x00A9D692+146]
STDERR: 	content::protocol::TracingHandler::ReadyToCommitNavigation [0x00A9E51B+123]
STDERR: 	content::RenderFrameDevToolsAgentHost::ReadyToCommitNavigation [0x00AA151D+61]
STDERR: 	content::WebContentsImpl::ReadyToCommitNavigation [0x00DA46EF+127]
STDERR: 	content::NavigationHandleImpl::ReadyToCommitNavigation [0x00B16972+2898]
STDERR: 	content::NavigationHandleImpl::WillProcessResponse [0x00B12E47+359]
STDERR: 	content::NavigationRequest::OnResponseStarted [0x00B1B159+1561]
STDERR: 	content::NavigationURLLoaderImpl::OnReceiveResponse [0x00BCD077+183]

Comment 18 by tikuta@chromium.org, Jul 6 

STDERR: Backtrace:
STDERR: 	base::debug::StackTrace::StackTrace [0x01B67F40+32]
STDERR: 	base::debug::StackTrace::StackTrace [0x01B676FD+13]
STDERR: 	logging::LogMessage::~LogMessage [0x01B7FAA3+83]
STDERR: 	base::Process::Pid [0x01BA333B+91]
STDERR: 	content::protocol::TracingHandler::SetupProcessFilter [0x00B6E5D2+146]
STDERR: 	content::protocol::TracingHandler::ReadyToCommitNavigation [0x00B6F46B+123]
STDERR: 	content::RenderFrameDevToolsAgentHost::ReadyToCommitNavigation [0x00B724AD+61]
STDERR: 	content::WebContentsImpl::ReadyToCommitNavigation [0x00E7685F+127]
STDERR: 	content::NavigationHandleImpl::ReadyToCommitNavigation [0x00BE82E2+2898]
STDERR: 	content::NavigationHandleImpl::WillProcessResponse [0x00BE47B7+359]
STDERR: 	content::NavigationRequest::OnResponseStarted [0x00BECAC9+1561]
STDERR: 	content::NavigationURLLoaderImpl::OnReceiveResponse [0x00C9E9C7+183]
STDERR: 	base::internal::FunctorTraits<void (__thiscall content::NavigationURLLoaderImpl::*)(scoped_refptr<network::ResourceResponse>,mojo::StructPtr<network::mojom::URLLoaderClientEndpoints>,std::unique_ptr<content::NavigationData,std::default_delete<content::Nav [0x00CA29A2+98]
STDERR: 	base::internal::Invoker<base::internal::BindState<void (__thiscall content::NavigationURLLoaderImpl::*)(scoped_refptr<network::ResourceResponse>,mojo::StructPtr<network::mojom::URLLoaderClientEndpoints>,std::unique_ptr<content::NavigationData,std::default [0x00CA291C+92]
STDERR: 	base::debug::TaskAnnotator::RunTask [0x023F9312+306]
STDERR: 	base::internal::IncomingTaskQueue::RunTask [0x023E44EC+108]
STDERR: 	base::MessageLoop::RunTask [0x01B88BE7+519]
STDERR: 	base::MessageLoop::DeferOrRunPendingTask [0x01B88F3D+157]
STDERR: 	base::MessageLoop::DoWork [0x01B891B7+583]
STDERR: 	base::MessagePumpForUI::DoRunLoop [0x01B8AFA8+120]
STDERR: 	base::MessagePumpWin::Run [0x01B8AB0E+110]
STDERR: 	base::MessageLoop::Run [0x01B88707+119]
STDERR: 	base::RunLoop::Run [0x01BA422C+204]
STDERR: 	content::BrowserMainLoop::MainMessageLoopRun [0x00ADC09A+298]
STDERR: 	content::BrowserMainLoop::RunMainMessageLoopParts [0x00ADBE86+70]
STDERR: 	content::BrowserMainRunnerImpl::Run [0x00ADE51E+142]
STDERR: 	LayoutTestBrowserMain [0x023CF2B0+944]
STDERR: 	LayoutTestBrowserMain [0x023CF15C+604]
STDERR: 	content::ShellMainDelegate::RunProcess [0x01B593A7+167]
STDERR: 	content::RunBrowserProcessMain [0x00A0B923+83]
STDERR: 	content::ContentMainRunnerImpl::Run [0x00A0C1EB+459]
STDERR: 	service_manager::Main [0x01FE32AF+735]
STDERR: 	content::ContentMain [0x00A0B873+51]
STDERR: 	wWinMain [0x000F1050+80]
STDERR: 	__scrt_common_main_seh [0x047B1DFA+248] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
STDERR: 	BaseThreadInitThunk [0x76EB336A+18]
STDERR: 	RtlInitializeExceptionChain [0x77C19902+99]
STDERR: 	RtlInitializeExceptionChain [0x77C198D5+54]
STDERR:

Comment 19 by alph@chromium.org, Jul 6 

Indeed. Sorry, my fault, missed one more place. Fix is on the way.
Project Member

Comment 20 by bugdroid1@chromium.org, Jul 6 

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

commit a6c1fa1bb83ef29562c22ee56b17433ed0d6955a
Author: Alexei Filippov <alph@chromium.org>
Date: Fri Jul 06 22:45:49 2018

DevTools: Update tracing process filters when process is ready.

Drive-by: Fix a failing DCHECK on Pid() invoked on a non-ready process.

BUG= 848398 , 849887 

Change-Id: I1df89b5027ec5ed85235566427dd767ade092fa0
Reviewed-on: https://chromium-review.googlesource.com/1128055
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573099}
[modify] https://crrev.com/a6c1fa1bb83ef29562c22ee56b17433ed0d6955a/content/browser/devtools/protocol/tracing_handler.cc
[modify] https://crrev.com/a6c1fa1bb83ef29562c22ee56b17433ed0d6955a/content/browser/devtools/protocol/tracing_handler.h

Comment 21 by pfeldman@chromium.org, Dec 5

Status: Archived (was: Assigned)
Test failures are processed as a part of a dedicated triage, bulk-closing the bugs.
►

Sign in to add a comment