Thanks for the log file.

Fully symbolized sample is attached. Looks like there's a large GC happening in a nested runloop. It may be helpful to get a Chrome trace as well from about:tracing using the "Javascript and rendering" setting.

Deleted: bug-599209.txt 432 KB

bug-599209.txt 432 KB View Download

We will get this to you the next time it happens. Appreciate you looking.

What is the memory consumption of the process? What were the changes to the extension code?

We are still waiting for this to reproduce in-house again, so I don't have have exact memory data. I can say that memory holds steady when it gets into this state -- a coworker left it running over an entire weekend. It also happens separately in each user profile, a coworker had 2 processes spinning.

We don't know of any specific extension code that could cause this. I have tried to pause the background page a number of times while in this state to see if I can catch what was causing it in our code -- but there is never anything executing in our code.

If there is any specific memory stats that you want, please let us know and we would be happy to collect them the next time it happens.

Thank you for providing more feedback. Adding requester "hablich@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Please include a screenshot from the Chrome task manager including the column 'JavaScript memory'.

Attached are screenshots of CPU usage and Javascript memory between 2ish hours. Also attached is the trace. 

Chrome has been open for about 3 days without restarting.

Deleted: Screen Shot 2016-04-14 at 1.16.01 PM.png 88.3 KB

	Screen Shot 2016-04-14 at 1.16.01 PM.png 88.3 KB View Download

Deleted: Screen Shot 2016-04-14 at 2.24.41 PM.png 123 KB

	Screen Shot 2016-04-14 at 2.24.41 PM.png 123 KB View Download

Deleted: trace_lpCPU.json.gz 2.8 MB

trace_lpCPU.json.gz 2.8 MB Download

I don't know why but that trace has nothing but the sampling thread captured, and nothing from the browser--only renderers. Can you try taking another trace? Select "Javascript and rendering" as the trace option, and maybe try with "Web Developer" as well.

Sorry, here we are: attached.

Deleted: trace_lpCPU2.json.gz 7.9 MB

trace_lpCPU2.json.gz 7.9 MB Download

rsesek@ is the trace in #8 useful? I'm not sure how to tell which process corresponds with which extension, but there is a suspicious amount of CG happening in pid 67154.

I've seen LastPass get stuck at 100% CPU a few times recently (Chrome 50.0.2661.75, Windows 10). only happens with LastPass out of the dozens of extensions I use, and stops when I disable and re-enable it. I'll grab a trace next time.

67154 refers to the LastPass extension. You can know this by looking at the Task Manager screenshots under the Process ID column.

Here's another example on OS X -- I've found this is far more likely to happen if I leave several.    If you'd like me to leave it in this state let me know.  I've noticed this is far more likely to happen if you have many google docs / google sheets open

Deleted: SpinningThread.png 90.8 KB

	SpinningThread.png 90.8 KB View Download

Deleted: trace_spinningthread.json.gz 1.1 MB

trace_spinningthread.json.gz 1.1 MB Download

Due diligence: When was the last time the LastPass extension got updated? Do you see any correlation between a specific LastPass extension version and a Chrome version?

I found case from a LastPass customer that reported this issue with Chrome 46 and LastPass 3.2.41 back in November 2015. Since then we have gotten reports of it here and there. It only seems to happen when Chrome has been running for a few days.

chantie, is your extension using worker threads? The trace in #13 looks like we are stuck in a worker/GC cycle. I suspect that this has something to do with the extension code.

hpayer@ and ulan@ WDYT?

hablich@ -- we do not use worker threads yet -- and in my trace, the background page is paused -- there's no javascript extension code running at all and there's no difference in CPU usage. 

@hablich -- This has happened with old and new versions of LastPass -- I don't see a correlation between any specific versions.

Assigning to this weeks memory sheriff, hpayer@ could you have a look please?

I've encountered this issue quite a lot (for several months, at least), usually when I have a ton (30+) of tabs open.
Chrome 49.0.2623.112
LastPass 4.1.6

Deleted: trace_test.json.gz 800 KB

trace_test.json.gz 800 KB Download

Deleted: Screenshot 2016-04-22 01.03.58.png 118 KB

	Screenshot 2016-04-22 01.03.58.png 118 KB View Download

I have encountered this issue quite often and just submitted a support ticket to Lastpass. I was on Version 49.0.2623.112 (64-bit) but just upgraded to Version 50.0.2661.86 (64-bit). 

Once the process goes to 100% the only way it will stop is if I kill the extension or restart Chrome. Happy to provide a log file if I can -- let me know what would help. 

Deleted: Screen+Shot+2016-04-21+at+9.22.47+PM.png 279 KB

	Screen+Shot+2016-04-21+at+9.22.47+PM.png 279 KB View Download

Could you please run Chrome with --js-flags="--trace-gc --trace-gc-verbose"? With that we would see GC activity.

Another thing that is odd: in #8 and #13 the JS live memory is extremely high, and even higher than committed which cannot be.

I saw that JS live memory issue too (see attached, 1st process is LastPass).

Deleted: Screenshot 2016-04-22 00.59.07.png 162 KB

	Screenshot 2016-04-22 00.59.07.png 162 KB View Download

Ignoring committed memory (it's not accurate for large objects I think), we are close or even above the heap limit of 1.4GB for live objects. We do more GCs when we are close to the limit, as the alternative would be crashing with out of memory.

Of course there could be a leak so that live memory accumulates.

The live memory/committed memory counters have to be fixed. This is confusing and misleading.

If the live memory counter is correct, that would indeed suggest that the extension is leaking some memory. That could explain the massive GC load close to the maximum heap size of 1.4G.

Anyhow, --js-flags="--trace-gc --trace-gc-verbose" would help.

I would also suggest to use dev tools to look into potential memory leaks.

I also ran into this issue many times with Lastpass, I had about 10 tabs open when it happened just now. I also had another browser open at the same time (without any extensions). CPU usage goes over 100% for Lastpass and remains that way until I kill Lastpass from the Chrome task manager. I think I also had Chrome open for a few days before it happened.

Deleted: Screen Shot of extension usage.png 56.7 KB

	Screen Shot of extension usage.png 56.7 KB View Download

FYI -- We will be releasing a new version (4.1.9) of the extension today that should drastically improve our memory handling.

I suppose this ticket should remain open for a while to make sure this addresses the issue.

This issue was not resolved in 4.1.9. See attached for similar symptoms.

Deleted: Screenshot 2016-05-16 02.47.39.png 104 KB

	Screenshot 2016-05-16 02.47.39.png 104 KB View Download

Many of the reports of this on the lastpass forum are from Mac users.  I'm using Fedora 23 Linux with Chromium 48.0.2564.116 and 4.1.9 and I get this problem at least once a week, so it's not just Mac users.  I run two copies of Chromium (one with --user-data-dir).  I use some Google Docs constantly in one, but never in the other, so it's not purely a Google Docs thing.  The runaway Lastpass can happen in either instance.

The runaway will sometimes happen when I'm off using some app besides Chromium, in another workspace, ie, I don't think it's related to visiting a site which exercises Lastpass or Chromium in a particular way.  It often seems quite spontaneous.

Next time I'll try invoking Chromium with --js-flags="--trace-gc --trace-gc-verbose".  What will that do? (Ie, if it collects info, where will it put it?)

Those who believe this is an uncommon problem should Google[tm] for lastpass chrome cpu.

I have just hit this bug when my system ran out of memory, and I recall that every time it happened in the past I was using some memory-hungry application (or several memory-hungry Google services like Inbox and Docs, which are memory-hungry as well). Hope this helps.
I'm using Chromium on Debian Linux (stretch).

Encountered this again yesterday in Chrome 50.0.2661.102 and Lastpass 4.1.12. Has happened consistently for the past week or so, typically in the evening. 

Using Chrome 50.0.2661.102 and Lastpass 4.1.12
The process manager shows LastPass Extension using 100% CPU

Attached about:tracing before (bug) and after killing the extension (nobug)
The only difference seams to be PID 74684 doing a lot of GC stuff.

Deleted: trace_bug1.json.gz 1.4 MB

trace_bug1.json.gz 1.4 MB Download

Deleted: trace_nobug.json.gz 1006 KB

trace_nobug.json.gz 1006 KB Download

We are making another release today that should address the largest memory leak. Please let us know if this problem continues with 4.1.16 or greater.

Problem is ongoing in 4.1.16. I literally have to keep the extension turned off and only enable it for a few seconds when I'm trying to login to a site.

Was lastpass always using WebSocket/Native messaging in the cases where the cpu usage went high? I'm trying to understand if we have some kind of leak in those cases...

If someone can send a heap snapshot to bob at lastpass.com, it will be helpful. We made a number of fixes and haven't been able to reproduce lately.

LastPass uses websockets on mac. (It connects to a local socket. If helper app is not present, it will continue to try to connect in a loop.) We potentially use native messaging on Windows, if enabled by user. 

If someone experiencing the problem can post the text from their LastPass Icon=>More Options=>About LastPass page, then it should help answer lazyboy@chromium.org's question.

I have not been able to repro this for the past month.

> I have not been able to repro this for the past month.

I can confirm that it worked fine for me, too, lately. 

This issue hasn't appeared for me for a while now (whereas previously it was about once a week).

It seems that a memory leak was fixed in lastpass that caused this regression. I am closing this issue since it does not reproduce anymore.

"Closing" the loop :-)

Resolution: Culprit in lastpass.