question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Memory leak seemingly caused by typescript __awaiter helper

See original GitHub issue

We have been investigating a memory leak in our GraphQL server implementation and believe we have a root cause. We eliminated a lot of the network stack and other external things, and still have a leak.

There is a large retained memory in a Generator. We believe this is caused by https://github.com/microsoft/TypeScript/issues/36056, which is also referenced in https://stackoverflow.com/questions/58875158/nodejs-memory-growth-memory-leak-in-system. This matches our findings. We do not use any generators in our code, and we compile with babel using latest, which uses async/await natively.

Looking at the compiled Apollo source, it is littered with __awaiter.

I am wondering if Apollo can address this by releasing a version that does not use __awaiter and relies on native async/await?

We do not have many options to address this issue otherwise.

I can add additional information here from the heap dumps if necessary. I believe a test case can be created, unfortunately I do not have one readily available because I have been using our own internal (closed source) Apollo GraphQL server implementation.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:4
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

3reactions
abernixcommented, Feb 13, 2020

V8’s https://github.com/v8/v8/commit/d3a1a5b6c491, with the fix for this memory leak, has landed (after being delayed by the v12.15.0 security release) in Tuesday’s v12.16.0 as https://github.com/nodejs/node/commit/c004cf51c6 in https://github.com/nodejs/node/pull/31691.

That’s all to say, I hope you can upgrade to v12 again and be free of this! We’ll still bump the ECMAScript compilation target in the next major version.

I’m going to close this, but please feel free to ping me if it’s not in fact fixed. Thanks so much for reporting this originally! And a salute to @4n3ver for identifying the culprit. ❤️

1reaction
matthemstegercommented, Jan 31, 2020

I want to close the loop. We have downgraded to Node 10 and we are seeing stable memory usage in production.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Memory leak caused by event listeners attached to knockout ...
This is causing a memory leak as more and more event listeners are left for elements that no longer exist on the page....
Read more >
TypeScript: Modern JavaScript Development
and distributors will be held liable for any damages caused or alleged to be caused directly or ... always prevent us from facing...
Read more >
(¯`·.¸(¯`·.¸ You found the place that will teach you how to find ...
This site teaches basic and advanced search techniques for people interested in finding any kind of information on the web. Here are informations,...
Read more >
Martin Van Buren's Life at Lindenwald, 1839-1862
Van Buren National Historic Site] (Typescript, 1980); Lorraine M. Poll, Report on the Information Found in the Papers of Martin Van Buren.
Read more >
ZIM Updates - ZIMjs
We do ZIM to help the world be more creative and that is our reward. ... Memory leaks happen when objects are left...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found