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

Issue 678471 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
not on Chrome anymore
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

TaskManager DCHECK if displayed columns changes during sampling

Project Member Reported by w...@chromium.org, Jan 5 2017

Issue description

Chrome Version: 57.0.2972.0
OS: Windows

What steps will reproduce the problem?
(1) Provoke TaskManager sampling to take a long time; in my case the SharedSampler had seemingly broken, so I was e.g. not getting any memory usage or idle wakeup updates.
(2) Change the columns being displayed, i.e. enable or disable a column. I enabled the Process Priority Column

This cause Chromium to hit a DCHECK due to the refresh_flags not matching (see screenshot).
 
Screenshot 2017-01-04 at 14.45.10 - Display 2.png
814 KB View Download
Cc: -stanisc@chromium.org nick@chromium.org
Owner: stanisc@chromium.org
Status: Assigned (was: Untriaged)
stanisc, can you please take a look?
I'll see if I can repro this.
I couldn't repro so far. The second column that was enabled was Idle Wakeups (512), not Priority as stated in repro steps.

There is an assumption in SharedSampler that for any given cycle flags are the same for all processes. I guess what's going here is that the refresh on background thread is taking longer than one second for whatever reason and a new refresh cycle with a different set of columns starts before results are posted from the background thread. In that case it is possible fairly unlikely for the new mismatch flags passed with a new Refresh() call.

I'll add a Sleep() in the sampler code to see if that helps to repro the bug. I guess this DCHECK could be safely removed. The worst that would happen is the new column results would be delayed by one cycle.
Sorry, unreadable sentence - posted comment #3 before finishing editing it.

What I meant to say is that if the background refresh is slow (delayed due to CPU scheduling) and a set of columns passed to SharedSampler has changed then yes, hitting this DCHECK is possible.

Comment 5 by w...@chromium.org, Jan 5 2017

Re #4: Yes, that was exactly the situation - SharedSampler had somehow got
into an unresponsive state (I was not getting memory nor Idle Wakeups
updates any more) and had been that way for several seconds. While in that
state I added a new column, which was when things crashed.

I wasn't able to repro the SharedSampler "hang" subsequently, though, so a
Sleep is probably the best approximation!
Status: Started (was: Assigned)
Reproduced DCHECK with an extra Sleep in the sampling code. Verified that removing the DCHECK is OK. The rest of the code handles this situation just fine.
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 6 2017

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

commit 929f43478f9acb732ce04c4a1209cf3cd1b7a582
Author: stanisc <stanisc@chromium.org>
Date: Fri Jan 06 17:15:10 2017

Removed errorneous DCHECK from TaskManager SharedSampler code

The DCHECK could be triggered if sampling of results by SharedSampler on
background thread took longer than refresh cycle (1 second) and at the
same time user added or removed one of TaskManager columns handled by
SharedSampler.

This DCHECK was an errorneous assumption. I removed it and added a comment
explaining this situation.

BUG= 678471 

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

[modify] https://crrev.com/929f43478f9acb732ce04c4a1209cf3cd1b7a582/chrome/browser/task_manager/sampling/shared_sampler_win.cc

Status: Fixed (was: Started)

Sign in to add a comment