sentry-electron: `walk` introduced in 1.5.2 leads to memory leak + crash

Versions + Platform

  • [ >= 1.5.2] SDK version - @sentry/electron@v?.?.?
  • [ witnessed on 9 and 10 ] Electron version - electron@v?.?.?
  • [ mac ] Platform - Windows/macOS/Linux

Description

Unfortunately I don’t have a reproducible demo to show for this, but it appears the introduction of the walk function in 1.5.2 causes my application to endlessly spin when that function is hit for a very certain input (I can’t pinpoint it, but it is fully replicable). When this occurs, my entire application would freeze and be unclickable, and eventually it would leak enough memory to crash. walk was seemingly introduced to break circular references, but I think in my case it has caused one that does not occur in 1.5.1.

While I don’t have a demo, I can get a maintainer or anyone interested in fixing this set up with my app so they can encounter the issue directly.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 27 (1 by maintainers)

Most upvoted comments

Thanks for the reports.

Add a logpoint at walk function head

Logging inside walk will cause breadcrumbs and scope updates to be generated which will in turn call walk.

The only time I’ve been able to trigger this was when we accidentally logged a huge object tree to the console

@timfish Thanks! You are right, make beforeBreadcrumb always return null solved my problem.

Sentry.init({
  dsn: 'xxx',
  beforeBreadcrumb = (breadcrumb, hint) => null,
});

It seems that the problem is caused by the following log printing (just some exception stack, It doesn’t seems to have any huge objects). localhost-1639020358884.log

Still exists in 2.5.4, unfortunately I don’t have a reproducible demo to show for this, but i can show you the stack.

image image

I’ve just managed to reproduce this myself locally. In my case console logging a seemingly basic object causes it to go off walking a huge recursive object tree and leaks around 1GB every 10 seconds!

My limited debugging so far suggests that the walk function is not correctly detecting circular references in some cases.

We are on it!