Search in files uses huge amounts of memory
Reported by
harald.d...@gmail.com,
Oct 16 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Go to https://www.patreon.com/ 2. Open dev tools and a system memory monitor 3. Go to the search tab that searches all files 4. Search for "wrap" (without the quotes) What is the expected behavior? Little to no change in memory consumption. What went wrong? A huge memory usage spike. Did this work before? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: May not matter in most cases, but i was on the brink of a full RAM at one point and the system started swapping due to this, which was rather unpleasant and halted all meaningful interaction for about a minute.
,
Oct 16 2017
,
Oct 17 2017
As per change log provided in c#1, possible suspect is https://codereview.chromium.org/2553503002 @dglazkov: Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change. Thanks!
,
Oct 17 2017
,
Oct 23 2017
Whoops, this got lost due to bad bisect/triage.
,
Oct 23 2017
That's probably search index taking some memory. I doubt that bisect from #c1 is correct. If anything, not searching in binary files could only reduce the amount of memory used, not increase it.
,
Oct 23 2017
dgozman@chromium.org, the bisect in #c1 was confirmed by reverting the suspected CL. Obviously there's something wrong with instantiating the file object.
,
Oct 23 2017
Not sure what file object you are talking about, but we'll take a look.
,
Oct 23 2017
FWIW, reverting r437467 in resources.pak fixes the bug only in r437467 - r454138. Then another change comes into the mix and reintroduces the bug between 454138 (good) and 454152 (bad) https://chromium.googlesource.com/chromium/src/+log/9b550534..fd7fc207?pretty=fuller Suspecting r454150 "DevTools: Only provide static script content to UISourceCode" All found bisect ranges were quadruple-checked. Memory (private bytes) was observed in ProcessExplorer.
,
Oct 23 2017
OTOH, the *underlying* bug may be caused by another CL in the range from #c1 so it'd be sensible if a project member does a per-revision bisect of 437459 (good) - 437468 (bad).
,
Dec 14 2017
krajshree@ could u please try a per revision biscet.
,
Dec 15 2017
Tested the issue on Win-7 using chrome reported version #61.0.3163.100, chrome version #57.0.2946.0 and chrome version #50.0.2624.0. Following are the steps followed to reproduce the issue. ------------ 1. Navigated to https://www.patreon.com/ 2. Opened dev tools and a system memory monitor 3. Clicked search tab that searches all files 4. Searched for "wrap" (without the quotes) 5. Observed that there is little change in memory consumption. Note: Same behaviour is observed in both chrome version #57.0.2946.0 revision(437422) and M50 build. Attached screen casts for reference. lushnikov@/woxxom@ - Could you please check the attached screen casts and please let us know if anything missed from out side. per revision bisect results can't be provided if the behaviour is inconsistent. Thanks...!!
,
Dec 15 2017
#12, you're not using devtools search. See the attached screenshot. I've re-verified #c1 and the main regression range 437459 (good) - 437468 (bad) is still correct. As well as the secondary range r503914 (long) - r503922 (short) that shortens the memory consumption spike. Current Stable and Canary still spike RAM usage.
,
Dec 15 2017
Important note: when bisecting versions newer than 64.0.3244.0 (r506220), use "Private memory" column in Task Manager because the new "Memory footprint" column is lying about the actual memory usage as observed by cross-checking "Physical memory" usage delta in SysInternals Process Explorer, which is the indisputable arbiter in these matters.
,
Dec 15 2017
Adding and RBS for M65 for tracking purpose.
,
Dec 15 2017
Long text lines are killing us here. They create a huge amount of work for blink and result in a 8s layout on my macbook. Timeline attached. The patch in #c1 probably changes amount of matches, thus long results are collapsed by default and not rendered. Removing RBS - this is not a regression issue; we've never had a viewport for the search panel.
,
Dec 18 2017
Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using chrome latest stable #63.0.3239.108 and latest canary #65.0.3298.0. Bisect Information: ===================== Good build: 57.0.2946.0 Revision(437422) Bad Build : 57.0.2947.0 Revision(437705) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/f26da5af712a45c4ee62d79e6da2530a591ce987..486b1f4872b106bebd2c970f433ee21fcfedb78a From the above change log suspecting below change Review-Url: https://codereview.chromium.org/2564733002 lushnikov@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Dec 19
DevTools bug triage: closing low-priority bugs that don't have much demand. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by woxxom@gmail.com
, Oct 16 2017