Out of memory on exception serialization that contains a jQuery element

[AdriVanHoudt]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:

Version:

4.2.3

Description

Using angular@1.7.5

1. do console.warn(angular.element($0)) ($0 represents the selected element in the elements tab of Chrome dev tools)
2. then do Sentry.captureException(new Error('test'))

It returns an id and then after a while crashed the tab due to out of memory exception.
I'm not sure why, probably due to the serializer going to deep (related to #1395 ?)
I will look into using before-breadcrumb to mitigate this for me for now but would be nice if Sentry can handle this out of the box.

[AdriVanHoudt]

Maybe I should mention that we load jQuery so angular.element() is basically the same as $()

[AdriVanHoudt]

This seems to happen for regular DOM nodes as well

[AdriVanHoudt]

More precisely when they are in breadcrumb.data.extra.arguments

[kamilogorek]

Duplicate of #1707
I'll get this fixed soon.

[denodaeus]

I still seem to be running into this issue with the below versions:
"@sentry/browser": "^4.4.2",

Here's a stack of when it finally crashes:

/**
 * safeNormalize()
 *
 * Creates a copy of the input by applying standardizer function on it and parsing it back to unify the data
 */
function safeNormalize(input) {
    try {
        return JSON.parse(JSON.stringify(input, standardizer()));
    }
    catch (_oO) {
        return '**non-serializable**';
    }
}
exports.safeNormalize = safeNormalize;

My use case is that I'm using the jQuery validate plug in in my app, which catches errors and logs validation messages. Normally, these errors do not seem to bubble up to the console (form validation errors), but in this circumstance I just installed the stock sentry with no extra configuration in a react app and get an error every time I the form hits an error on the validate() function.

I tried the work around that was posted in the other linked issue:

beforeBreadcrumb(breadcrumb, hint) {
      const crumb = breadcrumb;
      console.log('breadcrumb => ', breadcrumb, ", hint =>", hint) //eslint-disable-line
      if (crumb && crumb.error && crumb.error.data) {
        crumb.error.data.extra.arguments = [];
      }
      //eslint-disable-line
      return crumb;
    },

However, this doesn't work, and this is the last thing logged:

breadcrumb =>  {timestamp: 1544758757.379, category: "console", data: {…}, level: "error", message: "%o has no name assigned [object HTMLInputElement]"}category: "console"data: {extra: {…}, logger: "console"}level: "error"message: "%o has no name assigned [object HTMLInputElement]"timestamp: 1544758757.379__proto__: Object , hint => 

[denodaeus]

Actually, I thought this was the case but it might be a little further up the stack. jQuery validate will log an error if an input to be validated is missing a name attribute, and it logs the DOM element directly to the console.

Here is a screenshot:

This is pretty easy to reproduce:

1. Install the above version of sentry
2. Throw an error containing a reference to a DOM node using the DOM APIs:

throw new Error(document.querySelector("#cool"));

Where #cool is an input element with a value set (stringified would be [object HTMLInputElement])

The browser (Chrome 70.0.3538.110) will hang until an OOM crash, on the above stack.

It looks like this might be somewhat related but not the same issue as reported, so I can create a new issue instead. Sorry for the confusion, it just originally looked exactly identical to the OP's issue.

[kamilogorek]

This is pretty easy to reproduce:
Install the above version of sentry
Throw an error containing a reference to a DOM node using the DOM APIs:
throw new Error(document.querySelector("#cool"));

Tried exactly this and cannot reproduce the issue.

[denodaeus]

https://stackblitz.com/edit/react-sentry-crash

[kamilogorek]

Reopened so i wont lost this thread, as im out of office till January.

[gotbahn]

any accessing of dom freezes, crashes in 4.4+
in 4.5+ sometimes we see runtime errors

cost us a lot of time, to find out that this comes from Sentry

[string-areeb]

Still facing this in 4.5.3

This happens for me if the logged element has a custom tag

Happens in normal case as well

Happens for elements rendered with Vue

[buremba]

After hours of debugging, we finally found the root issue and had to remove Sentry from our product. We use Nuxt.js and the version of this library is 4.5.3.

[kamilogorek]

@buremba we fixed 2 important issues with decycle method in 4.5.4, you may want to give it a try - https://github.com/getsentry/sentry-javascript/blob/master/CHANGELOG.md#454

[buremba]

@kamilogorek We upgraded to 4.6.1 but the issue still exists. Please see https://cl.ly/57191404a1af

[adriaanmeuris]

We've upgraded to 4.6.4 recently to fix other issues. Can confirm this happens in the latest version, in a node environment - triggering an out of memory error:

[adriaanmeuris]

@kamilogorek is this issue fixed in the most recent 5.x release?

[HazAT]

@adriaanmeuris This issue should be fixed with 4.6.6 and 5.0.x

[adriaanmeuris]

@HazAT unfortunately not - we're running 4.6.6 in production which caused the exact same OOM exception while decycling:

Confirmation of version:

Memory usage rises to >2GiB until it triggers the OOM-exception, after which PM2 restarts the crashed application:

[kamilogorek]

Is there a way that you could provide a repro case that we could use to debug this issue?

[adriaanmeuris]

I believe this is closely related to #1395 but since the application crashes, I have no clue which error occurred exactly to reproduce.

Do you have any suggestions to log the stack of the error to the console before Sentry would parse it? That would help me to track down the exact issue. Other ideas, greatly appreciated

[kamilogorek]

Closing the issue as a part of large repository cleanup, due to it being inactive and/or outdated. There's a large chance that this issue has been solved since.
Please do not hesitate to ping me if it is still relevant, and I will happily reopen and work on it.
Cheers!