Sentry-javascript: Uncaught hole

Created on 21 Nov 2017  路  6Comments  路  Source: getsentry/sentry-javascript

What is the current behavior?

Delete the last word in input field, the browser will blocking until raven-js throw Uncaught hole exception in below code:

try {
        // Attempt to invoke user-land function
        // NOTE: If you are a Sentry user, and you are seeing this stack frame, it
        //       means Raven caught an error invoking your application code. This is
        //       expected behavior and NOT indicative of a bug with Raven.js.
        return func.apply(this, args);
      } catch (e) {
        self._ignoreNextOnError();
        self.captureException(e, options);
        throw e;
      }

What is the expected behavior?

Raven.js version: 3.20.1 and Using npm package.
browser: chrome
OS: MacOS, windows 10
React: 0.14.3
Hosted Sentry by ourselves (8.21.0)

Most helpful comment

I recently encountered this in one of our apps. the cause was a big object, that had a bunch of circular references in it passed to a breadcrumb, and caused the stringify to fail, as it simply ran out of memory when trying to stringify such object.

I may be able to recreate this in codepen or plunker, but the thing is - I'm not sure if that's something that can/would be fixed. One interesting way to fix this would be to limit the depth of the object passed in to say 10, which would, in some cases, prevent it from becoming too large.

All 6 comments

Hey @WhatAKitty, can you provide a reproducible test case that we could use to test this behavior?

@kamilogorek I cannot reproduce this in jsfiddle, but it actually happened in my workplace. And it still in there when I upgrade react to 0.14.9

@kamilogorek I use html script import, the error changed to :

Uncaught TypeError: Illegal invocation
    at Object.stringify (<anonymous>)
    at e (raven.js:2791)
    at e.ha (raven.js:1740)
    at e.fa (raven.js:1663)
    at e.P (raven.js:1605)
    at e.X (raven.js:1380)
    at e.N (raven.js:1286)
    at e.z (raven.js:1274)
    at raven.js:241
    at k (raven.js:2276)
    at HTMLBodyElement.l (raven.js:2341)
    at Object.trigger (jquery.min.js:4)
    at HTMLInputElement.eval (jquery.min.js:4)
    at Function.each (jquery.min.js:2)
    at n.fn.init.each (jquery.min.js:2)
    at n.fn.init.trigger (jquery.min.js:4)
    at b._onFieldValidated (bootstrapValidator.min.js:11)
    at b.updateStatus (bootstrapValidator.min.js:11)
    at b.validateField (bootstrapValidator.min.js:11)
    at HTMLInputElement.eval (bootstrapValidator.min.js:11)
    at HTMLInputElement.dispatch (jquery.min.js:3)
    at HTMLInputElement.r.handle (jquery.min.js:3)
    at HTMLInputElement.d (raven.js:363)

and this always happened while the input has an validation. And at same time, the browser will throw an error: [Deprecation] 'window.webkitStorageInfo' is deprecated. Please use 'navigator.webkitTemporaryStorage' or 'navigator.webkitPersistentStorage' instead.

How abt your client environment? such as Chrome with several plugins on Mac OSX, information like these would be help, as far as I know there is no such webkitStorageInfo variable use in raven-js, try another browser or use it in stealth mode see if it's reproduce.

I recently encountered this in one of our apps. the cause was a big object, that had a bunch of circular references in it passed to a breadcrumb, and caused the stringify to fail, as it simply ran out of memory when trying to stringify such object.

I may be able to recreate this in codepen or plunker, but the thing is - I'm not sure if that's something that can/would be fixed. One interesting way to fix this would be to limit the depth of the object passed in to say 10, which would, in some cases, prevent it from becoming too large.

As we released Release Candidate of our SDK v4, we clean up some of the issues. Please feel free to let me know and I'll reopen this issue if this will ever happen in the new version. Cheers!

Was this page helpful?
0 / 5 - 0 ratings