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

Issue 702304 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug


Participants' hotlists:
Hotlist-4


Sign in to add a comment

chrome://discards showing always zero discards on cyan

Project Member Reported by semenzato@chromium.org, Mar 16 2017

Issue description

Title says it all.  The chrome://discard page shows 0 discards even after many discards have happened.  Clicking on the "discard" link for a page does not increase the count.

Actually, "always" is too strong.  I just noticed that now it shows that 1 tab was discarded, the Calendar tab.

OK now it's working... grrr.

The chrome log is printing these frequently:

1415:1415:0316/113125.617879:WARNING:oom_memory_details.cc(46)] Tab Discards Memory details (2460 ms):

followed by a tab list.  But it's not clear what event is prompting these messages.  So the situation is confusing.


 
Cc: puneetster@chromium.org bashi@chromium.org
Kenichi, could this be connected to the recent work on the tab discarder?
Labels: -Pri-2 Pri-1
Raising priority because this is making it hard to debug current issues.

Comment 3 by bashi@chromium.org, Mar 28 2017

This only happens when --enable-feature=MemoryCoordinator is specified. Is my understanding correct? I only changed tab discarding behavior when the flag is specified.
#3 we noticed this problem before we were aware of the MemoryCoordinator feature, so this happened with whatever setting is the default (which I assume is ON).

Comment 5 by bashi@chromium.org, Mar 28 2017

It's disabled by default but I'm running a finch experiment on Dev/Canary with 50% probability weight. Probably you were in the experiment group.

I couldn't reproduce the issue though. "Discard" links are working on my ChromeOS device (regardless of memory coordinator is enabled/disabled).

#5 thanks.  As I should have mentioned, this behavior was observed on a ToT build.

Sign in to add a comment