Can you try with disabled extensions? Maybe related to my reported issue 880102?

Can you also record a sample of the process with the high cpu usage in the Activity.app and attach it here? Thanks.

Even though I kill all the extensions and tabs, the memory used still increased. 

And I had try to disabled all extensions, but issue still exists.

And yesterday, I noticed that after the chrome run out of my memory, it will decreased to normal finally after some time.

I had attached a sample for chrome from Activity.app. With both heavy cpu usage and heavy memory used. Any wrong with this sample? I had recoded another sample:

Deleted: “Google Chrome” Sample.txt 170 KB

“Google Chrome” Sample.txt 170 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The chrome will run out of my memory, and the system will keep throwing memory warning, and some of my application will be killed. And just now, I was forced logout due to memory run out...

Seems to be fixed already.

    2412 Thread_2371389: TaskSchedulerBackgroundBlockingWorker
    + 2410 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff7468abf9]
    + ! 2410 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff7468b50d]
    + !   2410 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff7468b661]
    + !     2410 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x10beb4000 + 0x2525427  [platform_thread_posix.cc:78]
    + !       2410 base::internal::SchedulerWorker::RunBackgroundPooledWorker()  (in Google Chrome Framework)  load address 0x10beb4000 + 0x24dce64  [scheduler_worker.cc:0]
    + !         2410 base::internal::SchedulerWorker::RunWorker()  (in Google Chrome Framework)  load address 0x10beb4000 + 0x24dd0ff  [type_traits:4520]
    + !           2410 base::internal::TaskTracker::RunAndPopNextTask(scoped_refptr<base::internal::Sequence>, base::internal::CanScheduleSequenceObserver*)  (in Google Chrome Framework)  load address 0x10beb4000 + 0x24e453a  [task_tracker.cc:437]
    + !             2410 base::internal::TaskTrackerPosix::RunOrSkipTask(base::internal::Task, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x10beb4000 + 0x2524ff4  [task_tracker_posix.cc:23]
    + !               2410 base::internal::TaskTracker::RunOrSkipTask(base::internal::Task, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x10beb4000 + 0x24e4d1e  [trace_event.h:1106]
    + !                 2410 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x10beb4000 + 0x2470452  [callback.h:99]
    + !                   2410 DevToolsFileWatcher::SharedFileWatcher::DispatchNotifications()  (in Google Chrome Framework)  load address 0x10beb4000 + 0x47d966b  [__tree:1129]
    + !                     2323 DevToolsFileWatcher::SharedFileWatcher::GetModificationTimes(base::FilePath const&, std::__1::map<base::FilePath, base::Time, std::__1::less<base::FilePath>, std::__1::allocator<std::__1::pair<base::FilePath const, base::Time> > >*)  (in Google Chrome Framework)  load address 0x10beb4000 + 0x47d9484  [devtools_file_watcher.cc:113]
    + !                     : 1260 base::FileEnumerator::Next()  (in Google Chrome Framework)  load address 0x10beb4000 + 0x251df69  [file_enumerator_posix.cc:24]
    + !                     : | 1259 stat$INODE64  (in libsystem_kernel.dylib) + 10,0,...  [0x7fff744c551a,0x7fff744c5510,...]

Oh, wait. You say it's 71.0.3542.0. It must be something new then.

Follow these instructions to take a heap dump:
https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/heap_profiler.md#how-to-obtain-a-heap-dump-m66_linux_macos_windows

That will tell us what is leaking.

The CPU profile suggests it spends most of the time in allocating strings for DevToolsFileWatcher::SharedFileWatcher
So I think that's likely the cause.

Can someone from the devtools team look into this?

Lusha, can it be a large workspace?

+1

There is a HORRIFYING memory leak in devtools in the most recent stable (69.0.3497.81).

I repeat:
THIS IS ON STABLE.

How the f. can something like this even slip in?

It is reproducible in the following way:
1. Open devtools, the inspector.
2. Open a handy memory tracking app, i.e. task manager, process explorer, whatever linux has.
3. Start running your mouse around DOM elements in the inspector. No clicking needed. Just fly around the inspector, highlighting elements.
4. Watch CPU usage blaze into the stratosphere!

Deleted: Chrome Memory leak.jpg 36.4 KB

	Chrome Memory leak.jpg 36.4 KB View Download

Martin, thank you for the report.

That really looks bad. Would you mind opening a separate bug for your issue as it seems unrelated to this one. I can do it myself if you like.

> Lusha, can it be a large workspace?

@alph: nah, I just tried with 80Gb folder and works fine. I can't repro on my mac and Chrome 71.

@Martin: I can't reproduce this on neither Chrome 69 or Chrome 71.

Attaching entire symbolized profile for your convenience.

Deleted: symbolized profile 2.txt 201 KB

symbolized profile 2.txt 201 KB View Download

I had add a folder to workspace in FileSystem of devtools, which I think is the cause of this issue.

The folder is a front-end project. 

After opening chrome, chrome run normally. But when I open the devtools, the memory increased rapidly.

Removing node_modules of the frontend-end project or just removing the project in FileSystem of the devtools, solved the issue...

There are many symlink in my node_modules, maybe this is the cause? 

Reproduce:
1. using `cnpm` to install node_modules in a front-end project.(cnpm is a replacement for npm, which ues symlink mode for node_modules, and will create lots of symlink).
2. add the project to the filesystem of the devtools.
3. Memory increased rapidly..(if not, reopen the chrome and devtool).

use npm or yarn work well.

a recursive symlink perhaps?

Yes, I think recursive symlink is the cause.

Reproduce:
1. Create a folder name A
2. In A folder, create two folder B and C
3. In B folder, make two symlink to B and C
4. In C folder, make two symlink to B and C
5. Create some dirty file in B or C
6. Open Chrome and add A folder into workspace(filesystem) 

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

commit ec7fdd0d23b0c3e60610d16a566771ca04fe24cd
Author: Alexei Filippov <alph@chromium.org>
Date: Thu Sep 13 04:16:42 2018

Make FileEnumerator do not follow infinite symlink loops.

When recursive mode is set visit each inode no more than once.

BUG= 880692 

Change-Id: I1a3709831630f4b418c0553ed7af92b91761c7c6
Reviewed-on: https://chromium-review.googlesource.com/1213951
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590921}
[modify] https://crrev.com/ec7fdd0d23b0c3e60610d16a566771ca04fe24cd/base/files/file_enumerator.h
[modify] https://crrev.com/ec7fdd0d23b0c3e60610d16a566771ca04fe24cd/base/files/file_enumerator_posix.cc
[modify] https://crrev.com/ec7fdd0d23b0c3e60610d16a566771ca04fe24cd/base/files/file_enumerator_unittest.cc

Awesome, thanks!

Is this well tested in canary? How safe is it?

Not yet in Canary. I'll test it as soon as it arrives.

Other than that I'd say it's of moderate safety, but crucial for DevTools users who use workspaces and npm. We expect increase of the amount of such users in the coming month, so we definitely would like to see this fix merged.

Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the fix in Canary 71.0.3552.2
It works.

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

commit 2d7724e47a5d90932c5789a27b76bd43f4c5d3ca
Author: Alexei Filippov <alph@chromium.org>
Date: Fri Sep 14 20:35:13 2018

Make FileEnumerator do not follow infinite symlink loops.

When recursive mode is set visit each inode no more than once.

BUG= 880692 
TBR=alph@chromium.org

(cherry picked from commit ec7fdd0d23b0c3e60610d16a566771ca04fe24cd)

Change-Id: I1a3709831630f4b418c0553ed7af92b91761c7c6
Reviewed-on: https://chromium-review.googlesource.com/1213951
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#590921}
Reviewed-on: https://chromium-review.googlesource.com/1226035
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#426}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/2d7724e47a5d90932c5789a27b76bd43f4c5d3ca/base/files/file_enumerator.h
[modify] https://crrev.com/2d7724e47a5d90932c5789a27b76bd43f4c5d3ca/base/files/file_enumerator_posix.cc
[modify] https://crrev.com/2d7724e47a5d90932c5789a27b76bd43f4c5d3ca/base/files/file_enumerator_unittest.cc

Yes, problem solved!