memory leak in browserTracingIntegration.ts

[SimonSiefke]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

dont know

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

1. Go to https://syntax.fm/
2. Click on shows
3. Click on videos
4. Repeat steps 2-3 several times
5. Notice the number of sentry related functions seems to grow each time

Expected Result

The number of sentry related functions stays constant

Actual Result

The number of sentry related functions seems to grow each time

Additional Context

Possible solution: add {once: true} to event listener options to automatically clean up the listener:

// browserTracingIntegration.ts

// Enable auto finish of the pageload span if users are not explicitly ending it
if (isPageloadSpan && !enableReportPageLoaded && optionalWindowDocument) {
 optionalWindowDocument.addEventListener('readystatechange', () => {
 emitFinish();
 }, {once: true }); // clean up listener automatically

 emitFinish();
}

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear-code]

JS-2805

[andreiborza]

Hi @SimonSiefke, thanks for writing in.

We'll get this fixed.

[Lms24]

Notice the number of sentry related functions seems to grow each time

how do you notice this? Where is the screenshot coming from? We would like to reproduce this

[SimonSiefke]

Thanks for looking into this!

It's a bit complicated. I have a vscode-memory-leak-finder project https://github.com/SimonSiefke/vscode-memory-leak-finder/

And sometimes I use it to find memory leaks in VSCode. Now VSCode also has a builtin integrated browser.

And the way to reproduce the issue is to run a vscode-memory-leak-finder e2e test. The e2e test opens the VSCode integrated browser with the syntax.fm url and clicks on shows and video links several times.

video.mp4

The project supports different measure-leak measurements. named-function-count3 is a measurement where it looks at the heapsnapshot before and after and then looks which function counts have increased between the heapsnapshots.

This outputs json data like:

{
 "namedFunctionCount3": [
 {
 "count": 233,
 "delta": 227,
 "name": "ut",
 "originalLocation": "node_modules/.pnpm/@sentry+core@8.28.0/node_modules/@sentry/core/build/esm/tracing/sentrySpan.js:37:15",
 "originalName": "SentrySpan",
 "sourceLocation": "https://syntax.fm/_app/immutable/chunks/trace.DhgZlh6A.js:5:2481"
 },
 {
 "count": 108,
 "delta": 105,
 "name": "it",
 "originalLocation": "node_modules/.pnpm/@sentry+core@8.28.0/node_modules/@sentry/core/build/esm/scope.js:60:3",
 "originalName": "ScopeClass",
 "sourceLocation": "https://syntax.fm/_app/immutable/chunks/trace.DhgZlh6A.js:3:3061"
 }
 ],
 "isLeak": true
}

Based on the JSON data, I asked the AI about potential memory leaks in sentry, which then pointed out the readystatechange listener

optionalWindowDocument.addEventListener('readystatechange', () => {
 emitFinish();
});

And there is another JS file which can convert the json data to SVG.

Full reproduction steps using bash, tested with Ubuntu 26.04:

1. Ensure NodeJS 24.15.0 is used
2. Run this script:

git clone git@github.com:SimonSiefke/vscode-memory-leak-finder.git &&
cd vscode-memory-leak-finder &&
npm ci &&
node packages/cli/bin/test.js --run-skipped-tests-anyway --enable-extensions --only syntax-fm --runs 97 --measure named-function-count-3 --inspect-integrated-browser

The output json data will be in .vscode-memory-leak-finder-results/integrated-browser/named-function-count-3/syntax-fm-simple-browser-videos-shows.json

[andreiborza]

We tried to reason about when this could actually happen, that we setup more than on such listener, but given that pageloads are only happening once, unless the folks at Syntax set up multiple clients or start pageload spans multiple times, it's unlikely this was the actual reason.

We cleaned up the handler just in case anyway for good form, but it's unclear if this actually fixes the issue. We'll see in the next release :)