Memory leak for https.request() on ECONNRESET

[patrickd-]

• Version: 6.8.0, 7.0.0
• Platform: Ubuntu 16.04 (Linux patrickd 4.4.0-38-generic Fix for path.resolve containing relative path to another drive in windows #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux)
• Subsystem: https

I experience a memory leak when doing https requests to a host that resets the connection.

Reproduce by

1. starting node econnreset.js
   econnreset.js.txt
2. start node leak.js
   leak.js.txt
3. Observe process memory
   For me it goes up to 600MB with 10000 requests - and stays that way.

Heapdump is small

1. install node-heapdump (npm install heapdump)
2. comment in the require('heapdump')
3. run node econnreset.js and node leak.js
4. when it's done with the requests (no more CPU usage) execute kill -USR2 $pid.
   The resulting heapdump from a process with 600MB is only 100MB large.

Manual GC call has no effect

1. comment in global.gc();
2. start node econnreset.js and node leak.js --expose-gc
3. when it's done with the requests (no more CPU usage) it will execute the GC every second but the memory usage doesn't change.

Am I using https.request() wrong or is this an internal problem?

[imyller]

I have not verified, but there is a possibility that this is related to #8647 - which is not in 6.7.0

[patrickd-]

unfortunately I'm still able to reproduce this bug with node 6.8.0

[patrickd-]

also able to reproduce in 7.0.0

[bnoordhuis]

I had a look and it's a variation on #8871 (comment). Abridged version: catastrophic memory fragmentation because of how glibc allocates memory. There isn't much we can do about that except switch to a different memory allocator and that is not a trivial undertaking.

If you strace -o trace.log -e brk node leak.js, you will find that the brk addresses only go up, never down. On my FC24 x86_64 system, the difference between the lowest and the highest address is almost exactly 700 MB.

[patrickd-]

This seems to have been fixed by node version 7.2.0 (probably #9626)

Can no longer reproduce, closing

[tsheaff]

For me this issue was still present in v7.7.4, but fixed in v7.9.0. For posterity:

This code causes a large leak (50kb per call which adds up quickly on production):

request.get({ url: 'https://www.google.com' });

This code does not leak (https changed to http):

request.get({ url: 'http://www.google.com' });

using request package

I wish the bug had been better documented — was a critical one in our case as it took our server out of memory about once an hour.

[itslukej]

I'm able to reproduce this on v7.9.0

[bnoordhuis]

@itslukej Please file a new issue and include steps to reproduce.

[pizzachip]

Using http seems to slow down the leak for me vs https, but, it still leaks on v8.9.1

[knoxcard]

This ticket needs to be reopened?

[knoxcard]

Wonder if this can be resolved by using this instead???

https://github.com/request/request-promise