Sentry-javascript: 100% CPU load in chrome/firefox

[apollovy]

Macbook Pro Early 2011
OS X 10.11.6 (15G19009)
Chrome 65.0.3325.162 / Firefox 58.0.2 / FIrefox 59.0.2

When going to issues list page or a particular issue page, 100% CPU per tab is consumed, even in incognito mode with all the plugins disabled.

• The version of Sentry you're using
  sentry.io
• Whether you're using Docker or another installation method
  Nope
• Include a stacktrace or other logs when relevant
  
  (Sorry for some Russian, but it's CPU time >100%, trust me 😇)
• Include a redacted version of your configuration when relevant
  Nope

[MaxBittker]

hi @apollovy!
This sounds bad and i'd love to fix it but i'm not sure I can reproduce it.
In chrome everything looks fine, and firefox i'm seeing high CPU usage while scrolling and clicking around, but it doesn't seem too extra-ordinary.

Would it be possible for you to use chrome or FF's performance tabs to record a short profile and upload that here so we could inspect? Or is there any other information you could provide to help me reproduce this? (do the pages in question have a higher than average amount of data displayed in them?)

(Thanks for disabling plugins, we've seen this in the past be caused by react development browser plugins like react-sight )

[apollovy]

Hi, @MaxBittker. Sorry for a little bit long delay.
Right now I see no such behavior, but I'm pretty sure I was seeing it during last couple of weeks.
The only thing that differs in my current state and the usual is that I currently have no AC power connected and external display. I'll test those things before long and write a report here.

[MaxBittker]

i definitely believe that it happened - we've had such issues in the past. If you can get more information I'd love to fix this

[MaxBittker]

happy to re-open this if anyone has information

[akiyamasho]

This isn't really helpful, but I'll provide the info as much as I can.

This was happening on a page with a relatively deep React tree. The CPU usage would shoot up to 150% and would not go down anymore, and pausing the scripts shows a breakpoint in raven.js in this specific line:

before = function(evt) {
                  // need to intercept every DOM event in `before` argument, in case that
                  // same wrapped method is re-used for different events (e.g. mousemove THEN click)
                  // see getsentry/sentry#724

Everything I do in the DOM becomes painfully slow, including clicking on things or moving the cursor in an input. Doing a performance profile shows that the DOM is being painted slowly.

The worse part is this happens randomly so I don't have any concrete replication steps. I'll provide more info if I discover anything else.

[kamilogorek]

@carlo-cogentlabs I have a suspicion (not confirmed yet, as it's very hard to repro this behavior) that it may have something to do with serializing dom nodes in order to show them in breadcrumbs.

If you'd do any more testing and stumble upon this issue, could you set a breakpoint inside this try/catch block https://github.com/getsentry/raven-js/blob/master/src/raven.js#L982 and see what's the input to htmlTreeAsString function?

[akiyamasho]

@kamilogorek sure! I'll return to this bug tomorrow and post whatever I find here. thanks for looking into this.

[akiyamasho]

@kamilogorek unfortunately, I could not replicate the issue after trying for some time. I'll add the breakpoint in the line you provided and keep you posted should this ever occur again.

[akiyamasho]

@kamilogorek I was able to replicate the issue after about 2 weeks, but when adding a breakpoint to htmlTreeAsString line, evt.target seems to simply be any item with a listener I click (e.g. - a button).

I found a lead, but it's not related to sentry. I was using a debugging extension in Chrome called React-Sight, and it was the one creating event listeners and DOM nodes faster than the GC can handle it. The DOM nodes, JS heap size, and event listeners shot up this much:

Surprisingly, the more updates that happened after the page starts to crawl, the easier it is to replicate the performance issue, and every update in React seems to create almost exponentially more nodes and listeners than before. It ended up showing an error in my console:

Uncaught Error: Message length exceeded maximum allowed length.
    at PortImpl.postMessage (VM2483 extensions::messaging:121)
    at Port.publicClassPrototype.(anonymous function) [as postMessage] (extensions::utils:138:26)
    at Object.sendMessageImpl (VM2483 extensions::messaging:399)
    at Object.<anonymous> (VM2396 extensions::runtime:57)
    at Object.handleRequest (VM2397 extensions::binding:64)
    at Object.<anonymous> (VM2397 extensions::binding:374)
    at window.addEventListener (content-script.js:17)
PortImpl.postMessage @ VM2604 extensions::messaging:121
publicClassPrototype.(anonymous function) @ VM2603 extensions::utils:138
sendMessageImpl @ VM2604 extensions::messaging:399
(anonymous) @ VM2606 extensions::runtime:57
(anonymous) @ VM2596 extensions::binding:64
(anonymous) @ VM2596 extensions::binding:374
window.addEventListener @ content-script.js:17
postMessage (async)
t.traverse16 @ fiber-hook.js:127
(anonymous) @ installHook.js:52
(anonymous) @ react-dom.development.js:5531
(anonymous) @ react-dom.development.js:5498
onCommitRoot @ react-dom.development.js:5548
commitRoot @ react-dom.development.js:11614
completeRoot @ react-dom.development.js:12502
performWorkOnRoot @ react-dom.development.js:12452
performWork @ react-dom.development.js:12370
performSyncWork @ react-dom.development.js:12347
batchedUpdates @ react-dom.development.js:12541
batchedUpdates @ react-dom.development.js:1939
dispatchEvent @ react-dom.development.js:4282
d @ raven.js:425
VM2604 extensions::messaging:121 Uncaught Error: Message length exceeded maximum allowed length.
    at PortImpl.postMessage (VM2483 extensions::messaging:121)
    at Port.publicClassPrototype.(anonymous function) [as postMessage] (extensions::utils:138:26)
    at Object.sendMessageImpl (VM2483 extensions::messaging:399)
    at Object.<anonymous> (VM2396 extensions::runtime:57)
    at Object.handleRequest (VM2397 extensions::binding:64)
    at Object.<anonymous> (VM2397 extensions::binding:374)
    at window.addEventListener (content-script.js:17)
PortImpl.postMessage @ VM2604 extensions::messaging:121
publicClassPrototype.(anonymous function) @ VM2603 extensions::utils:138
sendMessageImpl @ VM2604 extensions::messaging:399
(anonymous) @ VM2606 extensions::runtime:57
(anonymous) @ VM2596 extensions::binding:64
(anonymous) @ VM2596 extensions::binding:374
window.addEventListener @ content-script.js:17
postMessage (async)
t.traverse16 @ fiber-hook.js:127
(anonymous) @ installHook.js:52
(anonymous) @ react-dom.development.js:5531
(anonymous) @ react-dom.development.js:5498
onCommitRoot @ react-dom.development.js:5548
commitRoot @ react-dom.development.js:11614
completeRoot @ react-dom.development.js:12502
performWorkOnRoot @ react-dom.development.js:12452
performWork @ react-dom.development.js:12370
performSyncWork @ react-dom.development.js:12347
interactiveUpdates @ react-dom.development.js:12597
interactiveUpdates @ react-dom.development.js:1958
dispatchInteractiveEvent @ react-dom.development.js:4259
d @ raven.js:425
3VM2604 extensions::messaging:121 Uncaught Error: Message length exceeded maximum allowed length.
    at PortImpl.postMessage (VM2483 extensions::messaging:121)
    at Port.publicClassPrototype.(anonymous function) [as postMessage] (extensions::utils:138:26)
    at Object.sendMessageImpl (VM2483 extensions::messaging:399)
    at Object.<anonymous> (VM2396 extensions::runtime:57)
    at Object.handleRequest (VM2397 extensions::binding:64)
    at Object.<anonymous> (VM2397 extensions::binding:374)
    at window.addEventListener (content-script.js:17)

where content-script.js was traced from the React-Sight extension.

I'll still be looking into this just in case there's any correlation and will report it to React-Sight once I prove that it's really the extension that's causing it. For now I'd like to apologize for possibly reporting a false negative.

I'll keep updating this thread just in case.

[markstory]

Closing as this appears to have gone stale and there haven't been additional reports in the last couple months of this issue.

[Primajin]

I have the same issue still. I am rendering a fairly long dom tree of a table grid.
Every "row" is wrapped in an anchor. When clicking on the anchor I have attached an onclick event that normally uses a router to bring you to a different page.

I removed everything from the onclick event, except a console.log. When I just log out a 'hello world', everything is fine. But when I try to do anything with the event itself (even logging doesn't work) the CPU goes up to over 100 and the browser eventually breaks down after a couple of minutes hinting the sentryWrapped.

Hope that helps?

EDIT:
I was able to pinpoint it down to a couple of properties, that seem to have caused the high cpu load.
When I run:

  private handleRowClick = id => evt => {
    console.log(Object.keys(evt));
    Object.keys(evt).forEach(function(key, index) {
      if (~['_targetInst', '_dispatchInstances', 'target', 'currentTarget'].indexOf(key)) {
        console.log(key, ' at position ', index, ' is going to bust your cpu');
      } else {
        console.log(key, evt[key]);
      }
    });
  };

CPU doesn't spike at all and console is directly populated (except for '_targetInst', '_dispatchInstances', 'target', 'currentTarget' - where it still breaks).

[lauterry]

Hi

It seems that I have some related performance issues with sentry browser.

Is it normal that the sentryWrapped function is being called infinitely on my webpage ?

You can test it on https://lacollection.airfrance.fr/fr-FR/listing?strategy=navigationFirst

It randomly freezes my listing page

I'm using ABTASTY for ab test which script has continuous activities on my page :

The function below from ab tasty script is being called infinitely.

For some reasons, this also triggers sentryWrapped function infinitely which may results some performance issues.

Do you have some inputs regarding this case ?

Why the sentryWrapped function is being called ?

Best regards

[taylorthurlow]

I'm also having this issue in Firefox 71.0.1, macOS 10.15.2.

Here is a link to a Firefox profiler export (it's like 20MiB of JSON). In the middle of the profile I temporarily switch away from the tab, and then back again.