Possible memory leak in TLS(Wrap?) #1075

Closed
aredridel opened this Issue Mar 5, 2015 · 144 comments

Projects

None yet
@aredridel
Contributor

I'm diagnosing a problem when I run paypal's npm proxy https://github.com/krakenjs/kappa when run on iojs. After 300 requests for a 50kb tarball, memory allocated grows from 250 mb base to 450 mb.

I've run it under valgrind, and there's some things that look a bit suspicious around tlswrap, smalloc and some other crypto related bits. The interesting bits of the valgrind report are:

==31542== 827,216 bytes in 656 blocks are still reachable in loss record 1,214 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0x7450D8: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x6C868B: asn1_enc_save (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x6C2866: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x6C14FF: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x6C1BAB: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x6C2F0F: ASN1_item_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67CC9E: ssl3_get_server_certificate (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x681323: ssl3_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67958B: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679E1A: ssl23_write (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDBCEF: _ZN4node7TLSWrap7ClearInEv.part.43 (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542== 
==31542== 1,343,488 bytes in 328 blocks are still reachable in loss record 1,215 of 1,223
==31542==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0xCD825D: node::NodeBIO::PeekWritable(unsigned long*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCD8EEC: node::TLSWrap::OnAllocImpl(unsigned long, uv_buf_t*, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xD031D0: uv__read (stream.c:1089)
==31542==    by 0xD03967: uv__stream_io (stream.c:1219)
==31542==    by 0xD08CEC: uv__io_poll (linux-core.c:319)
==31542==    by 0xCFA955: uv_run (core.c:324)
==31542==    by 0xC87650: node::Start(int, char**) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x5C8E76C: (below main) (libc-start.c:226)
==31542== 
==31542== 2,303,504 bytes in 131 blocks are still reachable in loss record 1,216 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0x7450D8: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67BBAF: ssl3_setup_write_buffer (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67BCB1: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679000: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679CBA: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDCE78: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDD2B4: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x801781: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x828E02: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x1C66A79060BA: ???
==31542==    by 0x1C66A7CDC7AD: ???
==31542== 
==31542== 2,323,416 bytes in 131 blocks are still reachable in loss record 1,217 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0x7450D8: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67BD5F: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679000: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679CBA: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDCE78: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDD2B4: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x801781: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x828E02: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x1C66A79060BA: ???
==31542==    by 0x1C66A7CDC7AD: ???
==31542==    by 0x1C66A7CDC562: ???
==31542== 
==31542== 3,464,048 bytes in 197 blocks are still reachable in loss record 1,218 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0x7450D8: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67BBAF: ssl3_setup_write_buffer (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67BCB1: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679000: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679CBA: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDCE78: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDD2B4: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x1C66A7A43345: ???
==31542==    by 0x1C66A7EA169A: ???
==31542==    by 0x1C66A7CDC562: ???
==31542==    by 0x1C66A7924BC5: ???
==31542== 
==31542== 3,493,992 bytes in 197 blocks are still reachable in loss record 1,219 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0x7450D8: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x67BD5F: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679000: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x679CBA: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDCE78: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDD2B4: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x1C66A7A43345: ???
==31542==    by 0x1C66A7EA169A: ???
==31542==    by 0x1C66A7CDC562: ???
==31542==    by 0x1C66A7924BC5: ???
==31542==    by 0x1C66A7C08177: ???
==31542== 
==31542== 5,373,952 bytes in 328 blocks are still reachable in loss record 1,220 of 1,223
==31542==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0xCD8325: node::NodeBIO::Commit(unsigned long) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDD745: node::TLSWrap::OnReadImpl(long, uv_buf_t const*, uv_handle_type, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xD0335E: uv__read (stream.c:1156)
==31542==    by 0xD03967: uv__stream_io (stream.c:1219)
==31542==    by 0xD08CEC: uv__io_poll (linux-core.c:319)
==31542==    by 0xCFA955: uv_run (core.c:324)
==31542==    by 0xC87650: node::Start(int, char**) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x5C8E76C: (below main) (libc-start.c:226)
==31542== 
==31542== 7,422,722 bytes in 131 blocks are still reachable in loss record 1,221 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0xCAD6A2: node::smalloc::Alloc(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x801781: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x828E02: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x1C66A79060BA: ???
==31542==    by 0x1C66A79B20B8: ???
==31542==    by 0x1C66A791EA54: ???
==31542==    by 0x1C66A791EDA0: ???
==31542==    by 0x1C66A7D088BE: ???
==31542==    by 0x1C66A7D084D4: ???
==31542==    by 0x1C66A7D08272: ???
==31542==    by 0x1C66A7924BC5: ???
==31542== 
==31542== 11,162,414 bytes in 197 blocks are still reachable in loss record 1,222 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0xCAD6A2: node::smalloc::Alloc(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x801781: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x828E02: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x1C66A79060BA: ???
==31542==    by 0x1C66A79B20B8: ???
==31542==    by 0x1C66A791EA54: ???
==31542==    by 0x1C66A791EDA0: ???
==31542==    by 0x1C66A7EA5607: ???
==31542==    by 0x1C66A7D08272: ???
==31542==    by 0x1C66A7924BC5: ???
==31542==    by 0x1C66A7C08177: ???
==31542== 
==31542== 18,591,935 bytes in 20,677 blocks are still reachable in loss record 1,223 of 1,223
==31542==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31542==    by 0xCD8E91: node::TLSWrap::OnAllocSelf(unsigned long, uv_buf_t*, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDCEA0: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xCDD7B7: node::TLSWrap::OnReadImpl(long, uv_buf_t const*, uv_handle_type, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0xD0335E: uv__read (stream.c:1156)
==31542==    by 0xD03967: uv__stream_io (stream.c:1219)
==31542==    by 0xD08CEC: uv__io_poll (linux-core.c:319)
==31542==    by 0xCFA955: uv_run (core.c:324)
==31542==    by 0xC87650: node::Start(int, char**) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==31542==    by 0x5C8E76C: (below main) (libc-start.c:226)
==31542== 
==31542== LEAK SUMMARY:
==31542==    definitely lost: 10,464 bytes in 327 blocks
==31542==    indirectly lost: 63,532 bytes in 3,258 blocks
==31542==      possibly lost: 4,568 bytes in 64 blocks
==31542==    still reachable: 69,011,541 bytes in 206,575 blocks
==31542==         suppressed: 0 bytes in 0 blocks
==31542== 
==31542== For counts of detected and suppressed errors, rerun with: -v
==31542== ERROR SUMMARY: 42 errors from 42 contexts (suppressed: 2 from 2)

Any help or suggestions for what to look at to track this down would be wonderful.

Node 0.12 and 0.10 don't show this behavior with the same code (we're stress-testing io.js in parallel to shake stuff like this loose)

@bnoordhuis
Member

I wonder if there is a handle leak. I noticed that TLSWrap::OnReadSelf() creates a JS buffer object without a HandleScope. Does this patch make a difference?

diff --git a/src/tls_wrap.cc b/src/tls_wrap.cc
index 1647ab6..2b00d9e 100644
--- a/src/tls_wrap.cc
+++ b/src/tls_wrap.cc
@@ -641,6 +641,7 @@ void TLSWrap::OnReadSelf(ssize_t nread,
                          uv_handle_type pending,
                          void* ctx) {
   TLSWrap* wrap = static_cast<TLSWrap*>(ctx);
+  HandleScope handle_scope(wrap->env()->isolate());
   Local<Object> buf_obj;
   if (buf != nullptr)
     buf_obj = Buffer::Use(wrap->env(), buf->base, buf->len);
@jasisk
jasisk commented Mar 5, 2015

Providing a tiny bit of additional context: this is a graph of memory usage across 6 instances of our application from a few weeks back (4x node v0.10.3?, 1x node v0.12.0 in orange, 1x iojs v1.3.0 in red). Continuing to see the same behavior in 1.4.x.

rss

The application is a very simple proxy, seeing highs of ~350 reqs/sec though more consistently ~80-100. Each incoming request results in 1 to 4 outbound requests.

@indutny
Member
indutny commented Mar 5, 2015

Looking.

@indutny
Member
indutny commented Mar 5, 2015

It seems to be leaking TLSWrap instances, wtf.

@indutny indutny self-assigned this Mar 5, 2015
@indutny indutny added a commit to indutny/io.js that referenced this issue Mar 5, 2015
@indutny indutny stream_wrap: add HandleScope's in uv callbacks
Ensure that no handles will leak into global HandleScope by adding
HandleScope's in all JS-calling libuv callbacks in `stream_wrap.cc`.

Fix: nodejs#1075
b85f945
@indutny
Member
indutny commented Mar 5, 2015

Partial fix here: #1078

@GeoffreyPlitt

I've got a test here that reproduces the problem, comparing HTTP and HTTPS on 0.10, 0.12, and iojs.

https://github.com/GeoffreyPlitt/iojs_tls_bug

I'm going to try the partial fix above and see if it fixes my tests.

@indutny
Member
indutny commented Mar 6, 2015

It seems like these lines are partly responsible for this problem: https://github.com/iojs/io.js/blob/b27931b0fedc5fad638d637525aba84b2754ed5f/lib/_tls_wrap.js#L290-L305

@indutny
Member
indutny commented Mar 6, 2015

Found a JSStream leak, but so far don't have much progress on the main issue. It seems that cross-reference between StreamWrap and TLSWrap creates some non-collectible cycle, which should not be really possible. Most likely some bug in my code, but I can't say what exactly it is yet. Will continue tomorrow.

@Qard
Member
Qard commented Mar 6, 2015

Any particular reason that existence check/apply in the proxied methods runs on every call? Can it not be:

// Proxy HandleWrap, PipeWrap and TCPWrap methods
proxiedMethods.forEach(function(name) {
  res[name] = (handle[name] || function () {}).bind(handle);
});
@indutny
Member
indutny commented Mar 6, 2015

@Qard no reason, all of these methods are usually called once per handle lifetime.

@brendanashworth brendanashworth added the tls label Mar 6, 2015
@indutny
Member
indutny commented Mar 6, 2015

Looks like my patch is fixing the issue.

@Fishrock123 Fishrock123 added the bug label Mar 6, 2015
@indutny indutny added a commit that referenced this issue Mar 6, 2015
@indutny indutny stream_wrap: add HandleScope's in uv callbacks
Ensure that no handles will leak into global HandleScope by adding
HandleScope's in all JS-calling libuv callbacks in `stream_wrap.cc`.

Fix: #1075
PR-URL: #1078
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
583a868
@indutny
Member
indutny commented Mar 6, 2015

Should be fixed now, please confirm! ;)

@gm112
gm112 commented Mar 6, 2015

This bug has been causing me a lot of issues. I'll certainly build with this change and let you know how goes the memory usage.

@rvagg
Member
rvagg commented Mar 6, 2015

https://iojs.org/download/nightly/v1.4.4-nightly20150306dee07e2983/

Nightly with this change is there, please test, would love to have some feedback by the time 1.5.0 goes out later today.

@jasisk
jasisk commented Mar 6, 2015

Deployed the nightly. Will beat on it for a couple of hours and report back.

(fwiw, I know @aredridel reran her benchmark and saw the issue resolved as well.)

@gm112
gm112 commented Mar 6, 2015

I can confirm that for me, my memory usage is certainly much more stable. Before I would climb to several hundred megs with no problems.

I look forward to there being a full blown release.

@jasisk
jasisk commented Mar 6, 2015

Really early observations on the 1.4.4-nightly suggest there may be more. @aredridel is profiling it now.

blue: 0.10, purple: 0.12, green: 1.4.4-nightly

rss

@aredridel
Contributor

Without valgrind, it seems to have leveled things off somewhat.

However, it seems to grow still once I take a deeper look. Here's the larger chunks of valgrind's output:

==27619== 327,760 bytes in 482 blocks are still reachable in loss record 1,244 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x6E8E9E: EVP_CipherInit_ex (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x6608F6: tls1_change_cipher_state (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x642A6A: ssl3_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63B52F: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BD81: ssl23_write (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D1CF: node::TLSWrap::ClearIn() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D727: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBECBDA: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC3235D: uv__read (stream.c:1156)
==27619==    by 0xC32E8A: uv__stream_io (stream.c:1219)
==27619== 
==27619== 332,520 bytes in 489 blocks are still reachable in loss record 1,245 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x6E8E9E: EVP_CipherInit_ex (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x6608F6: tls1_change_cipher_state (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x648150: ssl3_do_change_cipher_spec (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x648F5E: ssl3_read_bytes (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63D657: ssl3_get_message (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63CFDC: ssl3_get_finished (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x642CAA: ssl3_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x64807F: ssl3_write_bytes (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D1CF: node::TLSWrap::ClearIn() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D727: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619== 
==27619== 356,000 bytes in 8,900 blocks are still reachable in loss record 1,246 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x66BAC8: c2i_ASN1_OBJECT (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67C7FA: asn1_ex_c2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67CBE4: asn1_d2i_ex_primitive (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DA2B: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DE2E: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DCED: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DFD5: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619== 
==27619== 366,592 bytes in 358 blocks are still reachable in loss record 1,247 of 1,265
==27619==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xC0A7C3: node::NodeBIO::Write(char const*, unsigned long) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0A033: node::NodeBIO::Write(bio_st*, char const*, int) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x689237: BIO_write (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BE9C: ssl23_write_bytes (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63AF21: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BC21: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CAFD: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CA1E: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A4743605: ???
==27619==    by 0x3E39A4B880FE: ???
==27619==    by 0x3E39A4A3DE02: ???
==27619== 
==27619== 379,640 bytes in 2,264 blocks are still reachable in loss record 1,248 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x6A3501: BUF_MEM_grow (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x682B03: x509_name_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D1CB: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DE2E: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DE2E: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E193: ASN1_item_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619== 
==27619== 418,760 bytes in 10,469 blocks are still reachable in loss record 1,249 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x66BAC8: c2i_ASN1_OBJECT (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67C7FA: asn1_ex_c2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67CBE4: asn1_d2i_ex_primitive (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DA2B: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DE2E: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DCED: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D92E: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619== 
==27619== 419,840 bytes in 410 blocks are still reachable in loss record 1,250 of 1,265
==27619==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xC0A7C3: node::NodeBIO::Write(char const*, unsigned long) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D652: node::TLSWrap::DoWrite(node::WriteWrap*, uv_buf_t*, unsigned long, uv_stream_s*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBEBADC: int node::StreamBase::WriteString<(node::encoding)4>(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0E9A4: void node::StreamBase::JSMethod<node::TLSWrap, &(int node::StreamBase::WriteString<(node::encoding)4>(v8::FunctionCallbackInfo<v8::Value> const&))>(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A46060BA: ???
==27619==    by 0x3E39A4B343B0: ???
==27619==    by 0x3E39A490E90E: ???
==27619==    by 0x3E39A49DE737: ???
==27619==    by 0x3E39A4624BC5: ???
==27619== 
==27619== 471,600 bytes in 393 blocks are still reachable in loss record 1,251 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x64539F: ssl3_new (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x662200: tls1_new (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x65735A: SSL_new (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0B472: node::TLSWrap::TLSWrap(node::Environment*, node::crypto::SSLWrap<node::TLSWrap>::Kind, node::StreamBase*, node::crypto::SecureContext*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0C59F: node::TLSWrap::Wrap(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A46060BA: ???
==27619==    by 0x3E39A49F0239: ???
==27619==    by 0x3E39A49EFD6A: ???
==27619== 
==27619== 524,280 bytes in 1 blocks are still reachable in loss record 1,252 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x77C42A: v8::internal::Malloced::New(unsigned long) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x8ED0A3: v8::internal::HeapProfiler::DefineWrapperClass(unsigned short, v8::RetainedObjectInfo* (*)(unsigned short, v8::Handle<v8::Value>)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBC7A13: node::Binding(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A46060BA: ???
==27619==    by 0x3E39A4670CC4: ???
==27619==    by 0x3E39A461EA54: ???
==27619==    by 0x3E39A466B52D: ???
==27619==    by 0x3E39A466AD78: ???
==27619==    by 0x3E39A466E272: ???
==27619== 
==27619== 559,838 bytes in 8,900 blocks are still reachable in loss record 1,253 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x671A3C: ASN1_STRING_set (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67C991: asn1_ex_c2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67CBE4: asn1_d2i_ex_primitive (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DA2B: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DE2E: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DCED: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DFD5: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619== 
==27619== 739,392 bytes in 30,808 blocks are still reachable in loss record 1,254 of 1,265
==27619==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xBE4BB5: node::smalloc::Alloc(node::Environment*, v8::Handle<v8::Object>, char*, unsigned long, v8::ExternalArrayType) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBCC4EA: node::Buffer::Use(node::Environment*, char*, unsigned int) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0B8D8: node::TLSWrap::OnReadSelf(long, uv_buf_t const*, uv_handle_type, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CBAD: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D72F: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBECBDA: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC3235D: uv__read (stream.c:1156)
==27619==    by 0xC32E8A: uv__stream_io (stream.c:1219)
==27619==    by 0xC37F01: uv__io_poll (linux-core.c:319)
==27619==    by 0xC29D09: uv_run (core.c:324)
==27619==    by 0xBC9220: node::Start(int, char**) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619== 
==27619== 938,448 bytes in 114 blocks are still reachable in loss record 1,255 of 1,265
==27619==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x8E9506: v8::internal::GlobalHandles::Create(v8::internal::Object*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBE4BCA: node::smalloc::Alloc(node::Environment*, v8::Handle<v8::Object>, char*, unsigned long, v8::ExternalArrayType) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBCC4EA: node::Buffer::Use(node::Environment*, char*, unsigned int) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0B8D8: node::TLSWrap::OnReadSelf(long, uv_buf_t const*, uv_handle_type, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CBAD: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D72F: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBECBDA: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC3235D: uv__read (stream.c:1156)
==27619==    by 0xC32E8A: uv__stream_io (stream.c:1219)
==27619==    by 0xC37F01: uv__io_poll (linux-core.c:319)
==27619==    by 0xC29D09: uv_run (core.c:324)
==27619== 
==27619== 1,215,604 bytes in 964 blocks are still reachable in loss record 1,256 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x680F2F: asn1_enc_save (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DAD1: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67DE2E: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67D4E4: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x67E193: ASN1_item_d2i (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63E927: ssl3_get_server_certificate (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x642EF1: ssl3_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63B52F: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BD81: ssl23_write (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619== 
==27619== 2,002,944 bytes in 489 blocks are still reachable in loss record 1,257 of 1,265
==27619==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xC0AD91: node::NodeBIO::PeekWritable(unsigned long*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0B829: node::TLSWrap::OnAllocImpl(unsigned long, uv_buf_t*, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBECB0C: node::StreamWrap::OnAlloc(uv_handle_s*, unsigned long, uv_buf_t*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC320CA: uv__read (stream.c:1089)
==27619==    by 0xC32E8A: uv__stream_io (stream.c:1219)
==27619==    by 0xC37F01: uv__io_poll (linux-core.c:319)
==27619==    by 0xC29D09: uv_run (core.c:324)
==27619==    by 0xBC9220: node::Start(int, char**) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x5C8E76C: (below main) (libc-start.c:226)
==27619== 
==27619== 2,303,504 bytes in 131 blocks are still reachable in loss record 1,258 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63DB07: ssl3_setup_write_buffer (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63DB6E: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63B02B: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BC21: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CAFD: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CA1E: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A46060BA: ???
==27619==    by 0x3E39A4A3E0A7: ???
==27619== 
==27619== 2,323,416 bytes in 131 blocks are still reachable in loss record 1,259 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63D9DD: ssl3_setup_read_buffer (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63DB60: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63B02B: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BC21: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CAFD: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CA1E: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A46060BA: ???
==27619==    by 0x3E39A4A3E0A7: ???
==27619== 
==27619== 6,295,072 bytes in 358 blocks are still reachable in loss record 1,260 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63DB07: ssl3_setup_write_buffer (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63DB6E: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63B02B: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BC21: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CAFD: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CA1E: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A4743605: ???
==27619==    by 0x3E39A4B880FE: ???
==27619==    by 0x3E39A4A3DE02: ???
==27619==    by 0x3E39A4624BC5: ???
==27619== 
==27619== 6,349,488 bytes in 358 blocks are still reachable in loss record 1,261 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63D9DD: ssl3_setup_read_buffer (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63DB60: ssl3_setup_buffers (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63B02B: ssl23_connect (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x63BC21: ssl23_read (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CAFD: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CA1E: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A4743605: ???
==27619==    by 0x3E39A4B880FE: ???
==27619==    by 0x3E39A4A3DE02: ???
==27619==    by 0x3E39A4624BC5: ???
==27619== 
==27619== 7,422,722 bytes in 131 blocks are still reachable in loss record 1,262 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xBE4AA8: node::smalloc::Alloc(node::Environment*, v8::Handle<v8::Object>, unsigned long, v8::ExternalArrayType) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBE49D3: node::smalloc::Alloc(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A46060BA: ???
==27619==    by 0x3E39A46B2198: ???
==27619==    by 0x3E39A461EA54: ???
==27619==    by 0x3E39A461EDA0: ???
==27619==    by 0x3E39A4A54D9E: ???
==27619==    by 0x3E39A4A549B4: ???
==27619==    by 0x3E39A4A54752: ???
==27619== 
==27619== 8,011,776 bytes in 489 blocks are still reachable in loss record 1,263 of 1,265
==27619==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xC0AE7A: node::NodeBIO::Commit(unsigned long) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D6FE: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBECBDA: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC3235D: uv__read (stream.c:1156)
==27619==    by 0xC32E8A: uv__stream_io (stream.c:1219)
==27619==    by 0xC37F01: uv__io_poll (linux-core.c:319)
==27619==    by 0xC29D09: uv_run (core.c:324)
==27619==    by 0xBC9220: node::Start(int, char**) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x5C8E76C: (below main) (libc-start.c:226)
==27619== 
==27619== 20,284,996 bytes in 358 blocks are still reachable in loss record 1,264 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xBE4AA8: node::smalloc::Alloc(node::Environment*, v8::Handle<v8::Object>, unsigned long, v8::ExternalArrayType) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBE49D3: node::smalloc::Alloc(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x3E39A46060BA: ???
==27619==    by 0x3E39A46B2198: ???
==27619==    by 0x3E39A461EA54: ???
==27619==    by 0x3E39A461EDA0: ???
==27619==    by 0x3E39A4B8B0C7: ???
==27619==    by 0x3E39A4A54752: ???
==27619==    by 0x3E39A4624BC5: ???
==27619== 
==27619== 27,708,244 bytes in 30,808 blocks are still reachable in loss record 1,265 of 1,265
==27619==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27619==    by 0xC0B881: node::TLSWrap::OnAllocSelf(unsigned long, uv_buf_t*, void*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0CB69: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC0D72F: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xBECBDA: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0xC3235D: uv__read (stream.c:1156)
==27619==    by 0xC32E8A: uv__stream_io (stream.c:1219)
==27619==    by 0xC37F01: uv__io_poll (linux-core.c:319)
==27619==    by 0xC29D09: uv_run (core.c:324)
==27619==    by 0xBC9220: node::Start(int, char**) (in /home/aredridel/t/node_modules/iojs-bin/node_modules/iojs-linux-x64/iojs-v1.4.2-linux-x64/bin/iojs)
==27619==    by 0x5C8E76C: (below main) (libc-start.c:226)
==27619== 
==27619== LEAK SUMMARY:
==27619==    definitely lost: 15,616 bytes in 488 blocks
==27619==    indirectly lost: 94,945 bytes in 4,868 blocks
==27619==      possibly lost: 4,369 bytes in 54 blocks
==27619==    still reachable: 101,753,796 bytes in 297,899 blocks
==27619==         suppressed: 0 bytes in 0 blocks
==27619== 
==27619== For counts of detected and suppressed errors, rerun with: -v
==27619== ERROR SUMMARY: 42 errors from 42 contexts (suppressed: 2 from 2)
@aredridel
Contributor

(ignore the v1.4.2 in the paths -- the actual binary being run is compiled from the pr/1078 branch)

@indutny
Member
indutny commented Mar 6, 2015

@aredridel this is bad news, as it could be related to https://code.google.com/p/v8/issues/detail?id=3949&thanks=3949&ts=1425654431 which I was experiencing with JSStream during debugging.

Being not able to reproduce this issue myself, I've pushed suggested patch to the: https://github.com/indutny/io.js/tree/test/paypal-leak . May I ask you to give it a try?

Thanks a lot!

@bnoordhuis
Member

@aredridel It's a crude hack but can you try this patch? If it keeps running, great. If it aborts, there's still a handle leak somewhere.

@aredridel
Contributor

Building now!

The actual instrumentation I'm using is the kappa package, configured to talk to a private (empty) npm registry over http, then to https://registry.npmjs.org/, then logging via good. The bulk of the work is that proxy, try each, moving on if there's a 404. I just tested with ab -c 10 -n 1000 on it. Pretty simple overall, doing https as a client from that hapi proxy.

@indutny
Member
indutny commented Mar 6, 2015

@bnoordhuis I think it could be v8 just not keeping up with it's partial GCs. Investigating.

@indutny
Member
indutny commented Mar 6, 2015

@aredridel pushed one more patch to that branch for you, please test ;)

@bnoordhuis what do you think about indutny@8ef701c ?

@indutny
Member
indutny commented Mar 6, 2015

@aredridel also, 1000 requests might not suffice. It doesn't seem like v8 is collecting any TLSWrap instances after 1000 connections, the whole thing happens much later.

@aredridel
Contributor

With the assertions: keeps running. So there's that. Trying the next patch on the branch.

@aredridel
Contributor

And without valgrind, that revision indutny@8ef701c seems to level off after 1200 or so requests. I'm gonna run that under valgrind and see if we've got any improvement there.

@rvagg rvagg added a commit that referenced this issue Mar 6, 2015
@rvagg rvagg 2015-03-06 io.js v1.5.0 Release
Notable changes:

* buffer: New `Buffer#indexOf()` method, modelled off `Array#indexOf()`.
  Accepts a String, Buffer or a Number. Strings are interpreted as UTF8.
  (Trevor Norris) #561
* fs: `options` object properties in `'fs'` methods no longer perform a
  `hasOwnProperty()` check, thereby allowing options objects to have
  prototype properties that apply. (Jonathan Ong)
  #635
* tls: A likely TLS memory leak was reported by PayPal. Some of the recent
  changes in stream_wrap appear to be to blame. The initial fix is in
  #1078, you can track the progress
  toward closing the leak at
  #1075 (Fedor Indutny).
* npm: Upgrade npm to 2.7.0. See npm CHANGELOG.md:
  https://github.com/npm/npm/blob/master/CHANGELOG.md#v270-2015-02-26
  for details including why this is a semver-minor when it could have
  been semver-major.
* TC: Colin Ihrig (@cjihrig) resigned from the TC due to his desire to do
  more code and fewer meetings.
25a7fc8
@aredridel
Contributor

With valgrind, it levels off at about the same place -- 1200 requests -- and the heap used after exit report from it is much smaller (13mb, not 100mb). The largest chunks left allocated and reachable, too, are smaller -- 2mb or so.

==575== 196,608 bytes in 48 blocks are still reachable in loss record 1,225 of 1,236
==575==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0xC0AEF7: node::NodeBIO::TryAllocateForWrite(unsigned long) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0AF84: node::NodeBIO::PeekWritable(unsigned long*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0B9B9: node::TLSWrap::OnAllocImpl(unsigned long, uv_buf_t*, void*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBECCAC: node::StreamWrap::OnAlloc(uv_handle_s*, unsigned long, uv_buf_t*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC322CA: uv__read (stream.c:1089)
==575==    by 0xC3308A: uv__stream_io (stream.c:1219)
==575==    by 0xC38101: uv__io_poll (linux-core.c:319)
==575==    by 0xC29F09: uv_run (core.c:324)
==575==    by 0xBC9280: node::Start(int, char**) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x5C8E76C: (below main) (libc-start.c:226)
==575== 
==575== 198,912 bytes in 777 blocks are still reachable in loss record 1,226 of 1,236
==575==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0xC0D04A: node::TLSWrap::EncOut() (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0DA9B: non-virtual thunk to node::TLSWrap::DoShutdown(node::ShutdownWrap*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBE95AE: node::StreamBase::Shutdown(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0E724: void node::StreamBase::JSMethod<node::TLSWrap, &(node::StreamBase::Shutdown(v8::FunctionCallbackInfo<v8::Value> const&))>(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x2B95418060BA: ???
==575==    by 0x2B9541DCB0B3: ???
==575==    by 0x2B9541E5953B: ???
==575==    by 0x2B9541E20F4B: ???
==575==    by 0x2B9541E594D7: ???
==575== 
==575== 199,168 bytes in 778 blocks are still reachable in loss record 1,227 of 1,236
==575==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0xC0D04A: node::TLSWrap::EncOut() (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0CC16: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x2B95418060BA: ???
==575==    by 0x2B9541D935EF: ???
==575==    by 0x2B9541C33F62: ???
==575==    by 0x2B9541824BC5: ???
==575==    by 0x2B9541B0ADB7: ???
==575==    by 0x2B9541E594D7: ???
==575==    by 0x2B9541DC3B2D: ???
==575== 
==575== 306,708 (44,000 direct, 262,708 indirect) bytes in 1,375 blocks are definitely lost in loss record 1,228 of 1,236
==575==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7294AC: sk_new_null (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x67DECD: asn1_template_noexp_d2i (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x67E063: asn1_template_ex_d2i (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x67D92E: ASN1_item_ex_d2i (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x67E193: ASN1_item_d2i (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC083E9: node::crypto::X509ToObject(node::Environment*, x509_st*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC03ECB: node::crypto::SSLWrap<node::TLSWrap>::GetPeerCertificate(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x2B95418060BA: ???
==575== 
==575== 524,280 bytes in 1 blocks are still reachable in loss record 1,229 of 1,236
==575==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0x77C42A: v8::internal::Malloced::New(unsigned long) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x8ED0A3: v8::internal::HeapProfiler::DefineWrapperClass(unsigned short, v8::RetainedObjectInfo* (*)(unsigned short, v8::Handle<v8::Value>)) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBC7A83: node::Binding(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x2B95418060BA: ???
==575==    by 0x2B954187108C: ???
==575==    by 0x2B954181EA54: ???
==575==    by 0x2B954186B52D: ???
==575==    by 0x2B954186AD78: ???
==575==    by 0x2B954186E272: ???
==575== 
==575== 710,400 bytes in 2,775 blocks are still reachable in loss record 1,230 of 1,236
==575==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0xC0D04A: node::TLSWrap::EncOut() (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0D927: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBECD7A: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC3255D: uv__read (stream.c:1156)
==575==    by 0xC3308A: uv__stream_io (stream.c:1219)
==575==    by 0xC38101: uv__io_poll (linux-core.c:319)
==575==    by 0xC29F09: uv_run (core.c:324)
==575==    by 0xBC9280: node::Start(int, char**) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x5C8E76C: (below main) (libc-start.c:226)
==575== 
==575== 737,280 bytes in 45 blocks are still reachable in loss record 1,231 of 1,236
==575==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0xC0AEF7: node::NodeBIO::TryAllocateForWrite(unsigned long) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0AFEB: node::NodeBIO::Commit(unsigned long) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0D8EE: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBECD7A: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC3255D: uv__read (stream.c:1156)
==575==    by 0xC3308A: uv__stream_io (stream.c:1219)
==575==    by 0xC38101: uv__io_poll (linux-core.c:319)
==575==    by 0xC29F09: uv_run (core.c:324)
==575==    by 0xBC9280: node::Start(int, char**) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x5C8E76C: (below main) (libc-start.c:226)
==575== 
==575== 799,036 bytes in 893 blocks are still reachable in loss record 1,232 of 1,236
==575==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0xC0BA11: node::TLSWrap::OnAllocSelf(unsigned long, uv_buf_t*, void*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0CD59: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0D91F: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBECD7A: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC3255D: uv__read (stream.c:1156)
==575==    by 0xC3308A: uv__stream_io (stream.c:1219)
==575==    by 0xC38101: uv__io_poll (linux-core.c:319)
==575==    by 0xC29F09: uv_run (core.c:324)
==575==    by 0xBC9280: node::Start(int, char**) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x5C8E76C: (below main) (libc-start.c:226)
==575== 
==575== 879,200 bytes in 50 blocks are still reachable in loss record 1,233 of 1,236
==575==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63DB07: ssl3_setup_write_buffer (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63DB6E: ssl3_setup_buffers (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63B02B: ssl23_connect (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63BC21: ssl23_read (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0CCED: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0CC0E: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x2B95418060BA: ???
==575==    by 0x2B9541D935EF: ???
==575== 
==575== 886,800 bytes in 50 blocks are still reachable in loss record 1,234 of 1,236
==575==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0x6F6004: CRYPTO_malloc (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63D9DD: ssl3_setup_read_buffer (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63DB60: ssl3_setup_buffers (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63B02B: ssl23_connect (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x63BC21: ssl23_read (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0CCED: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0CC0E: node::TLSWrap::Start(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7A0145: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x7C7F47: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x2B95418060BA: ???
==575==    by 0x2B9541D935EF: ???
==575== 
==575== 1,613,472 bytes in 196 blocks are still reachable in loss record 1,235 of 1,236
==575==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0x8E9506: v8::internal::GlobalHandles::Create(v8::internal::Object*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBE4CEA: node::smalloc::Alloc(node::Environment*, v8::Handle<v8::Object>, char*, unsigned long, v8::ExternalArrayType) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBCC55A: node::Buffer::Use(node::Environment*, char*, unsigned int) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0BA68: node::TLSWrap::OnReadSelf(long, uv_buf_t const*, uv_handle_type, void*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0CD9D: node::TLSWrap::ClearOut() (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC0D91F: node::TLSWrap::DoRead(long, uv_buf_t const*, uv_handle_type) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBECD7A: node::StreamWrap::OnRead(uv_stream_s*, long, uv_buf_t const*) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xC3255D: uv__read (stream.c:1156)
==575==    by 0xC3308A: uv__stream_io (stream.c:1219)
==575==    by 0xC38101: uv__io_poll (linux-core.c:319)
==575==    by 0xC29F09: uv_run (core.c:324)
==575== 
==575== 2,436,466 bytes in 43 blocks are still reachable in loss record 1,236 of 1,236
==575==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==575==    by 0xBE4BC8: node::smalloc::Alloc(node::Environment*, v8::Handle<v8::Object>, unsigned long, v8::ExternalArrayType) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0xBE4AF3: node::smalloc::Alloc(v8::FunctionCallbackInfo<v8::Value> const&) (in /home/aredridel/t/node_modules/.bin/iojs)
==575==    by 0x2B95419A75E5: ???
==575==    by 0x2B9541D96BB5: ???
==575==    by 0x2B9541C4A772: ???
==575==    by 0x2B9541824BC5: ???
==575==    by 0x2B9541B0ADB7: ???
==575==    by 0x2B9541E594D7: ???
==575==    by 0x2B9541D29DD1: ???
==575==    by 0x2B954181EA54: ???
==575==    by 0x2B9541C49AD9: ???
==575== 
==575== LEAK SUMMARY:
==575==    definitely lost: 44,000 bytes in 1,375 blocks
==575==    indirectly lost: 262,708 bytes in 13,461 blocks
==575==      possibly lost: 5,528 bytes in 110 blocks
==575==    still reachable: 13,063,533 bytes in 49,091 blocks
==575==         suppressed: 0 bytes in 0 blocks
==575== 
==575== For counts of detected and suppressed errors, rerun with: -v
==575== ERROR SUMMARY: 42 errors from 42 contexts (suppressed: 2 from 2)
@indutny
Member
indutny commented Mar 6, 2015

I guess this is a good news, right? :)

@jasisk
jasisk commented Mar 6, 2015

I deployed indutny/iojs@8ef701c but our traffic is ramping down a bit (Friday afternoon). Similar to @aredridel, initial observations are good but I'm driving more traffic to it to be sure.

@jasisk
jasisk commented Mar 6, 2015

I may have spoken too soon. It's more subtle (could be a result of traffic slowing), but still seems to be there (red: 1.4.4, blue: 0.10, orange 0.12):
screen shot 2015-03-06 at 6 05 08 pm

@indutny
Member
indutny commented Mar 6, 2015

@jasisk may I ask you to keep it running for some time just to make sure that it does not stabilize over longer time?

@jasisk
jasisk commented Mar 6, 2015

You got it. :) Will update the thread when a trend appears.

@bnb bnb referenced this issue in nodejs/evangelism Mar 6, 2015
Closed

Evangelism: Weekly Update Mar 6th #16

@gm112
gm112 commented Mar 7, 2015

Hey is anyone in this thread observing memory growth when there's a higher volume of socket hangups as well? (http/s)

@indutny
Member
indutny commented Mar 7, 2015

Oh, this is interesting. @gm112 how can I reproduce it?

@indutny
Member
indutny commented Mar 7, 2015

@jasisk @aredridel one more patch for you:

diff --git a/src/node_crypto.cc b/src/node_crypto.cc
index 9123207..a650d4f 100644
--- a/src/node_crypto.cc
+++ b/src/node_crypto.cc
@@ -1132,6 +1132,7 @@ static bool SafeX509ExtPrint(BIO* out, X509_EXTENSION* ext) {
       X509V3_EXT_val_prn(out, nval, 0, 0);
     }
   }
+  sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free);

   return true;
 }

This should fix definite leaks.

@jasisk
jasisk commented Mar 7, 2015

Great. Will deploy in the morning and report back. Thanks for all the work!

@indutny indutny added a commit that referenced this issue Mar 7, 2015
@indutny indutny crypto: fix leak in SafeX509ExtPrint
`ASN1_item_d2i`'s return value must be freed by the owner.

Fix: #1075
PR-URL: #1087
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
3b57819
@indutny
Member
indutny commented Mar 7, 2015

Cool, that patch is landed in v1.x, btw: 3b57819

@indutny
Member
indutny commented Mar 7, 2015

Ok, I finally installed kappa and I do observe growing RSS, going to spend some time with valgrind...

@indutny
Member
indutny commented Mar 7, 2015

Here is the heapsnapshot after 20k requests: https://cloudup.com/cSFN1VaukuF

@indutny
Member
indutny commented Mar 7, 2015

I think I know where the leak goes from :) 5 minutes, working on PR.

@indutny indutny added a commit to indutny/io.js that referenced this issue Mar 7, 2015
@indutny indutny tls: do not leak WriteWrap objects
Kill WriteWrap instances that are allocated in `tls_wrap.cc` internally.

Fix: nodejs#1075
0dee2ad
@indutny
Member
indutny commented Mar 7, 2015

This should fix it: #1090

@jasisk
jasisk commented Mar 7, 2015

Build from yesterday spiked overnight. Just deployed 3b57819 + 50c7421 + 0dee2ad.

@indutny indutny added a commit that referenced this issue Mar 7, 2015
@indutny indutny tls: do not leak WriteWrap objects
Kill WriteWrap instances that are allocated in `tls_wrap.cc` internally.

Fix: #1075
PR-URL: #1090
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
7f4c95e
@indutny
Member
indutny commented Mar 7, 2015

Should be fixed in latest master, and might be improved by 50c7421 . Please verify @aredridel @jasisk

@rvagg
Member
rvagg commented Mar 8, 2015

See release proposal v1.5.1 in #1096, I'd love to get feedback from everyone involved here as to whether it's worth shipping a new release to clear this up. Even incremental progress is good of course.

RC with the latest HEAD in v1.x is here: https://iojs.org/download/nightly/v1.5.1-nightly20150308fe36076c78/

@gm112
gm112 commented Mar 8, 2015

With the build before 50c7421 after 4 hours my server would sit at 150MB. After the same amount of time with similar traffic it sits at 60MB, which is also where the baseline is as well. Just thought I would provide some input.

@jasisk
jasisk commented Mar 8, 2015

Been running the build I mentioned above (included #1085 and #1090) for about nine hours, driving double the usual traffic. Not enough consistency in weekend traffic to have it level off, but it certainly looks a lot better.

purple: iojs, green: 0.10, red: 0.12
rss

Deploying the rc just in case, will report if anything looks different.

@rvagg
Member
rvagg commented Mar 8, 2015

@indutny @bnoordhuis can you comment on the shape of the graph for 0.12 vs io.js at all? the lack of increase is great but the delta is kind of large.

@indutny
Member
indutny commented Mar 8, 2015

@rvagg no comments yet, need to investigate. But it might be that v8's GC has became overall less aggressive.

@indutny
Member
indutny commented Mar 8, 2015

@rvagg also, considering that 0.10 has climbed to the levels of iojs, and 0.12 is below - it might be that paypal's proxy was encountering un-even load (cc @jasis). It appears to be never the case that 0.10 was higher that 0.12 in previous graphs.

@indutny
Member
indutny commented Mar 8, 2015

Nah, ignore last sentence, but anyway - it could be just uneven load.

@jasisk
jasisk commented Mar 8, 2015

Uneven load sounds right. A ton of automated builds kicking off every hour is what drives those spikes, which are a lot less prominent during the week. Plus, I'm disproportionately driving traffic to those machines. They're in a round-robin but still. I'll pull some stats to confirm the theory but I'll be putting everything back in the pool and restarting tonight so we should have better numbers by tomorrow afternoon.

@indutny
Member
indutny commented Mar 8, 2015

All of commits has landed in v1.x at this point.

@jasisk
jasisk commented Mar 9, 2015

A small update after a day. Looks like it's still leaking a bit.

red: 0.12, green: 0.10, purple: iojs.
rss

@indutny
Member
indutny commented Mar 9, 2015

Noooo!!!! Wtf!!! :) Will look into it tomorrow. Anyway it seems to be much better than it was, and at least we identified major source of it.

@indutny
Member
indutny commented Mar 9, 2015

@jasisk please continue your observations, I still have best hopes for that it'll stabilize at some point :)

@chrisdickinson
Contributor

This might be of interest as well, @wraithan and I tracked down a state where SSL_free wasn't getting called on v0.10 streams.

@indutny
Member
indutny commented Mar 9, 2015

@chrisdickinson this is very unlikely to be hit in io.js

@indutny
Member
indutny commented Mar 9, 2015

@jasisk could you please take a look at
screen shot 2015-03-09 at 10 48 18
? It seems that there is some retained sockets in kappa's code. I remember that you told me about the leaks that you had, I wonder if this is something expected or if it is caused by some behavior changed in io.js.

@jasisk
jasisk commented Mar 9, 2015

Intended to do some profiling today (particularly after @chrisdickinson's comment), will let you know.

For clarity (since I mentioned this to Fedor over IRC): we've had a slow leak in kappa for years, on the order of 10s of mbs after months of uptime. For our purposes, it's proven largely inconsequential so it's dropped off our list time and again. Time to look into it. :)

@indutny
Member
indutny commented Mar 9, 2015

Heh, thanks @jasisk ! I can confirm some sort of leak on my side, going to let RSS grow to 1gb and then will try to figure something out of the heapsnapshot locally.

@indutny
Member
indutny commented Mar 9, 2015

At least, valgrind seems to be happy at this point.

@indutny
Member
indutny commented Mar 9, 2015

Nah, it stabilized at 450mb RSS. Going to take a look at heapsnapshot anyway

@rvagg rvagg added a commit that referenced this issue Mar 9, 2015
@rvagg rvagg 2015-03-09 io.js v1.5.1 Release
Notable changes:

* tls: The reported TLS memory leak has been at least partially
  resolved via various commits in this release. Current testing indicated
  that there may still be some leak problems. Progress being tracked at:
  #1075
* http: Fixed an error reported at
  nodejs/node-v0.x-archive#9348 and
  npm/npm#7349
  Pending data was not being fully read upon an 'error' event leading to
  an assertion failure on socket.destroy().
  (Fedor Indutny) #1103
f19e9b6
@indutny
Member
indutny commented Mar 9, 2015

@jasisk I was unable to identify any relevant information in the heapsnapshot. Do you have any further graphs of RSS on your instance of kappa? Did it stabilize?

@jasisk
jasisk commented Mar 9, 2015

Same from my end.

Fresh start this morning (deployed 1a3ca82) and things haven't completely leveled off yet. That said, iojs is right in the mix which—previously—wasn't the case at this point in the day. Much more confident in saying you've caught it!

0.10 in purple, 0.12 in yellow, iojs in red.
RSS

@indutny
Member
indutny commented Mar 9, 2015

I guess we could assume it is resolved now? In any case - feel free to
reopen this ;)

On Monday, March 9, 2015, Jean-Charles Sisk notifications@github.com
wrote:

Same from my end.

Fresh start this morning and things haven't completely leveled off yet.
That said, iojs is right in the mix which—previously—wasn't the case at
this point in the day. Much more confident in saying you've caught it!

0.10 in purple, 0.12 in yellow, iojs in red.
[image: RSS]
https://cloud.githubusercontent.com/assets/62923/6563251/25edf830-c676-11e4-8d83-233d82af7e66.png


Reply to this email directly or view it on GitHub
#1075 (comment).

@jasisk
jasisk commented Mar 9, 2015

👍 thanks again!

@subfuzion subfuzion referenced this issue in nodejs/evangelism Mar 9, 2015
Closed

Evangelism: Weekly Update March 13th #41

@indutny
Member
indutny commented Mar 10, 2015

Thank you!

@indutny indutny closed this Mar 10, 2015
@yous yous referenced this issue in nodejs/nodejs-ko Mar 12, 2015
Merged

Added: 2015년 3월 6일 주간 뉴스 #35

@jasisk
jasisk commented Mar 12, 2015

Following up now that a few days have elapsed. While things are looking significantly better, there still appears to be a leak.

purple: iojs ~v1.5.1 (hash mentioned above), blue: 0.12, red: 0.10
rss

@trevnorris
Contributor

Thanks @jasisk. Going to repoen.

@trevnorris trevnorris reopened this Mar 12, 2015
@indutny
Member
indutny commented Mar 12, 2015

WHY?! 😞

@trevnorris
Contributor

@jasisk Do you have graph data over more time? The line looks like it leveled off at 1.1GB. Not saying that's acceptable, but it's curious why a near linear growth would have done that.

@jasisk
jasisk commented Mar 12, 2015

Was looking at that, myself. A tiny bit more data—and we just spiked across all instances:

rss

At 1.2gb, I have no reason to kick any of these over. I'll keep things running and check back in when it's clear a trend has emerged.

@indutny
Member
indutny commented Mar 12, 2015

@jasisk this is very frustrating, I had best hopes for the latest patch. Since I'm unable to reproduce this leak locally, may I ask you to install heapdump module, require('heapdump') from somewhere in code and try sending SIGUSR2 a couple of times during exposure of this leaks (better if it'd be significantly higher than v0.12 and v0.10)?

I wonder if it'll fall off to the v0.10/v0.12 levels after SIGUSR2? heapdump is starting a GC internally, so it might force-collect some stuff. Also, it would be great to take a look at the heapsnapshot itself too. Please contact me privately if you wish to do this, since the snapshot might contain sensitive data.

Thank you for a follow-up!

@jasisk
jasisk commented Mar 12, 2015

@indutny Yup. I was convinced of the fix 3 days ago so I never did any profiling, locally. after letting these processes go for a few more hours, I'll pull them down and instrument them. Will take a first pass at what I find and, if nothing obvious jumps out, I'll follow up elsewhere with you.

@indutny
Member
indutny commented Mar 12, 2015

@jasisk thank you! This sounds awesome.

@jasisk
jasisk commented Mar 13, 2015

Pulling down a couple of machines to instrument them but figured I'd give one more update before I do (iojs vs 0.12).

Still trending upward, unfortunately. Will update if / when the heap snapshots give me any insight.

rss

@trevnorris
Contributor

@jasisk Have you changed any flags like --max-old-space-size? If not the process should either be butting up against GC, if there's a problem in the V8 heap, or there's an external allocation run amok.

@jasisk
jasisk commented Mar 13, 2015

@trevnorris nope. No flags.

Heap dumps aren't showing anything out of the ordinary.

Here's the used heap graph for the iojs instance (yellow is averaging over 2 hours):
screen shot 2015-03-12 at 6 07 19 pm

@trevnorris
Contributor

@indutny seems like external allocations are leaking somewhere. thoughts?

@indutny
Member
indutny commented Mar 13, 2015

@trevnorris don't have any thoughts yet, fighting with #1140 at the moment.

Will take a look later today.

@indutny
Member
indutny commented Mar 13, 2015

@jasisk not sure how I missed it last time. May I ask you to give a try to this patch?

diff --git a/src/tls_wrap.cc b/src/tls_wrap.cc
index 49523bc..495729c 100644
--- a/src/tls_wrap.cc
+++ b/src/tls_wrap.cc
@@ -310,8 +310,10 @@ void TLSWrap::EncOut() {
   write_req->Dispatched();

   // Ignore errors, this should be already handled in js
-  if (!r)
+  if (!r) {
     NODE_COUNT_NET_BYTES_SENT(write_size_);
+    write_req->Dispose();
+  }
 }
@indutny
Member
indutny commented Mar 14, 2015

@jasisk updated the diff, there was a typo!

@indutny
Member
indutny commented Mar 14, 2015

Though, this might be not enough by itself. @jasisk : what if I'll give you a patch that logs some metrics into stderr, would it be possible to obtain this output from your testing environment?

@jasisk
jasisk commented Mar 14, 2015

Awesome! Will apply it shortly and report back tomorrow. Thanks again!

@rvagg
Member
rvagg commented Mar 14, 2015

See #1151 (comment) from @brycebaril. Not sure if this would accrue over runtime but perhaps it's getting caught up in stats collection @ https://github.com/krakenjs/kappa/blob/ff14ef91ba39472ca07d9f8f8c009eab9875071f/lib/stats.js#L57-L66

@jomo jomo added a commit to crafatar/crafatar that referenced this issue Mar 14, 2015
@jomo jomo use iojs 1.5.x, see nodejs/node#1103 + nodejs/node#1075 dfaa79b
@yosuke-furukawa yosuke-furukawa referenced this issue in nodejs/nodejs-ja Mar 14, 2015
Merged

Weekly 2015/03/13 #56

@jasisk
jasisk commented Mar 14, 2015

I would expect to see a more periodic growth in that case. It's pretty weak but, if I squint, I see the growth correlating with spikes in requests.

@indutny
Member
indutny commented Mar 14, 2015

@jasisk put the same patch in a PR: #1154

@indutny
Member
indutny commented Mar 14, 2015

@jasisk here is the patch for logging: indutny@01170cb , it will print following stuff every 5 seconds:

>>>> "43462684600589" counter "TLSWrap count", value "126"
>>>> "43462694565717" counter "WriteWrap count", value "1"

It should be enough to get these values when the RSS will spike, but it would be helpful to observe them over time too, if you have resources for this ;)

Thank you!

@indutny
Member
indutny commented Mar 14, 2015

@jasisk gosh patch in #1154 was a bit incorrect :) Here is a proper patch that landed e90ed79

@indutny
Member
indutny commented Mar 16, 2015

@jasisk May I ask you to try these two patches together: indutny@01170cb and indutny@9f233aa . It should log number of alive smalloc buffers. I wonder if we are unintentionally retaining any.

@indutny
Member
indutny commented Mar 16, 2015

According to @jasisk there is no leaks of TLSWrap/WriteWrap instances. Hopefully there are some Smalloc leaks and we'll be able to go somewhere from there ;)

@jasisk
jasisk commented Mar 16, 2015

Update graph of e90ed79 + indutny@01170cb (yellow is io.js, fairly light traffic until this morning):
RSS

Logged data showed TLSWrap / WriteWrap getting collected.

Building and deploying with the smalloc logging now.

@trevnorris
Contributor

This might be an issue with vm or related. From a conversation with @indutny:

Mar 05 16:38:34 <indutny>   I'm getting tons of ContextifyScript WeakCallback invokations
Mar 05 16:38:37 <indutny>   I wonder what this could mean
Mar 05 16:44:59 <indutny>   it does leak even without networking at all
@Olegas
Contributor
Olegas commented Mar 17, 2015

@jasisk Have you any data for v8's heapUsed/heapTotal for the same time (process.memoryUsage())?

@indutny
Member
indutny commented Mar 17, 2015

@trevnorris oh right! I forgot about it

@indutny
Member
indutny commented Mar 17, 2015

@trevnorris doesn't look to be the case now, though.

@jasisk
jasisk commented Mar 17, 2015

@Olegas yup. Don't have much data to go off of in the latest deploy—and we're not yet seeing the sharp increase—but here's my heap data.

blue: io.js, red: 0.12.0
center line is mean over 30m.

heap

@indutny
Member
indutny commented Mar 19, 2015

@jasisk is there any new data on your side? That would help a lot, thank you!

@jasisk
jasisk commented Mar 19, 2015

Fortunately, the sharp spikes just aren't happening. The smalloc logging seems to show they're being freed. TLSWrap seems to be freed regularly but, lately, seems to have a floor of 600. WriteWrap is more interesting, seemingly alternating between 1 and 590.

RSS is trending in a slightly upward angle, gaining ~10mb over 4 hours, during a time when 0.12 was flat. At this point (couple days of uptime), io.js is ~100mb higher at ~450mb as compared to 0.12's 350mb.

@indutny
Member
indutny commented Mar 19, 2015

Thank you, @jasisk . Unfortunately, it doesn't seem like anything bad is happening with either of TLSWrap/WriteWrap/smalloc. I can only suggest trying io.js 1.0.0 at this point, to isolate the change that introduced the leak.

@jasisk
jasisk commented Mar 19, 2015

You got it. Will deploy first thing in the morning, report back after a few days.

@indutny
Member
indutny commented Mar 19, 2015

Thank you, @jasisk!

@indutny
Member
indutny commented Mar 24, 2015

Any news, @jasisk ?

@jasisk
jasisk commented Mar 24, 2015

I ended up letting the last deploy run over the weekend just to make sure the initial hunch wasn't wrong since it had been a while since I'd let it run for a solid chunk of time.

RSS

Deployed v1.0.0 earlier tonight. We'll see how this goes.

@indutny
Member
indutny commented Mar 24, 2015

@jasisk I have a fix for you :) Might help a bit, or might fix it... (crossing my fingers).

Going to push it to PR in a bit.


Here are the other changes that needs to be re-checked:

  • Cluster change with a worker not sharing the handle
  • console.time() leaks?
  • EventEmitter removeListener
  • dualstack net changes
  • Timeout.prototype.unref changes

C++

  • UVException changes
  • ParseEncoding
  • Module loader changes? (unlikely)
  • SafeX509ExtPrint
  • GetPeerCertificate: if (cert != nullptr) X509_free(cert); if (peer_certs != nullptr)
  • InlineDecoder?! Hashes, ciphers, stuff like that, might be hapy's ETAG
  • v8 platform changes?
  • zlib changes? Unlikely, was reverted
  • StreamWrap: ClearError() introduction? Confirmed, leak
  • Utf8Value

cc @bnoordhuis : if you have time let's iterate this list together and verify that there are no leaks. (I've diffed all changes between v0.12 node.js and iojs v1.1.0 to find these).

@indutny indutny added a commit to indutny/io.js that referenced this issue Mar 24, 2015
@indutny indutny tls_wrap: fix BIO leak on SSL error 16a13c7
@indutny
Member
indutny commented Mar 24, 2015

@jasisk #1244 here you go, please give it a try. It is definitely fixing some leak, but it is really hard to tell how much yet.

@indutny indutny added a commit to indutny/io.js that referenced this issue Mar 25, 2015
@indutny indutny tls_wrap: fix this incredibly stupid leak
Always call `Done` on the WriteWrap, and ensure that `EncOut` will
consume all data in clear_in_ and invoke queued callbacks.

Fix: nodejs#1075
3327932
@indutny indutny added a commit that referenced this issue Mar 25, 2015
@indutny indutny tls_wrap: fix BIO leak on SSL error
Fix: #1075
PR-URL: #1244
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
e74b5d2
@indutny indutny added a commit that referenced this issue Mar 25, 2015
@indutny indutny tls_wrap: fix this incredibly stupid leak
Always call `Done` on the WriteWrap, and ensure that `EncOut` will
consume all data in clear_in_ and invoke queued callbacks.

Fix: #1075
PR-URL: #1244
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2ccc8f3
@indutny
Member
indutny commented Mar 25, 2015

@jasisk I have very good hopes for #1244 to fix problem that you are experiencing. (No need to redeploy, the landed commits are just a bit re-iterated patches that you applied in your testing).

@jasisk
jasisk commented Mar 26, 2015

Only 7 hours on it but haven't seen this shape before:
RSS

Huge 👍

@balupton

@jasisk what are you using to generate those graphs?

@jasisk
jasisk commented Mar 27, 2015

@balupton I'm using Grafana. We stuff all of our metrics into InfluxDB. Looking forward to the upcoming releases of both for various reasons. We also have Heka in the pipeline for metrics-triggered actions. We get graph annotations in Heka, I just need to push those back into Influx because Grafana supports them. twitter@jcse if you want to chat about it.

@indutny
Member
indutny commented Mar 27, 2015

@jasisk btw, how does the graph look after 2 days?

@jasisk
jasisk commented Mar 27, 2015

Hard to say at this point as we've only got 24 hours on it—I restarted three machines to get a proper comparison. I'm a little concerned by the trend over the last 6 hours but not enough yet to really conclude anything. Though even at this stage I can tell there's been substantial progress.

The build is #1244 on 2db758c.

purple: io.js, blue: 0.12.1, yellow: 0.12.0
RSS

@indutny
Member
indutny commented Mar 27, 2015

@jasisk looks like there is some leak still :) I'll continue looking into it then. Thank you!

@indutny
Member
indutny commented Mar 28, 2015

@jasisk may I ask you to take a heapsnapshot of the leaking process? I don't need the full file, just a want to take a sneak-peak look at the "Global Handles" contents. (See the attached picture).

screen shot 2015-03-28 at 09 50 52

UPDATE: would be cool to have a bit more items than what present on the attached screenshot :)

@jasisk
jasisk commented Mar 30, 2015

You got it. Instrumented, taking snapshots periodically. Will update when it's grown a bit.

@indutny
Member
indutny commented Apr 2, 2015

@jasisk how is it going? ;)

@jasisk
jasisk commented Apr 2, 2015

I don't have quite as much data as I'd like (pulled a couple of machines out of the pool for a bit) but, from what I can tell, looks like @rvagg and others' speculation was right: lots of timer refs from stats collection (unref'd timeout).

In any case, I put the machines back, kicked them over and am snapshotting every 10mb.

@Fishrock123
Member

@jasisk You mean like nodejs/node-v0.x-archive#8364 / #1152 (comment)?

#1152 (the original, but broken fix that is in node 0.12) is unfortunately broken beyond what I can repair. :|

@indutny
Member
indutny commented Apr 2, 2015

@jasisk no way! haha :) Well, I'd be more than happy if these are just a timers. Do they appear on a Global Handles list?

@Fishrock123
Member

See also 33fea6e#commitcomment-10440550 for more info on how / why the original #1152 is broken

@indutny
Member
indutny commented Apr 2, 2015

@Fishrock123 I'm going to address this problem now. Could you please assign it to me if we have any issue in a tracker?

@jasisk
jasisk commented Apr 2, 2015

Yup. That's exactly it.

0.12 on the left, io.js (custom build mentioned above) on the right
handles

@indutny
Member
indutny commented Apr 2, 2015

Yeah, it leaks timers now. I'll figure it out soon using @Fishrock123 patch.

On Thursday, April 2, 2015, Jean-Charles Sisk notifications@github.com
wrote:

Yup. That's exactly it.

0.12 on the left, io.js (custom build mentioned above) on the right
[image: handles]
https://cloud.githubusercontent.com/assets/62923/6972101/6c7f6220-d94f-11e4-8ee8-ef1eb2e85489.png


Reply to this email directly or view it on GitHub
#1075 (comment).

@indutny
Member
indutny commented Apr 3, 2015

@jasisk could you please give a try to #1330 ? I hope it'll help

@jasisk
jasisk commented Apr 3, 2015

👍 deploying now.

@Fishrock123
Member

@jasisk How's it looking? :D

@Fishrock123 Fishrock123 added a commit that referenced this issue Apr 6, 2015
@Fishrock123 Fishrock123 2015-04-06 io.js v1.6.4 Release
Notable changes:

* npm: upgrade npm to 2.7.5. See the npm CHANGELOG.md for details.
Includes two important security fixes.
https://github.com/npm/npm/blob/master/CHANGELOG.md#v275-2015-03-26
* openssl: preliminary work has been done for an upcoming upgrade to
OpenSSL 1.0.2a #1325 (Shigeki Ohtsu). See #589 for additional details.
* timers: a minor memory leak when timers are unreferenced was fixed,
alongside some related timers issues #1330 (Fedor Indutny). This
appears to have fixed the remaining leak reported in #1075.
* android: it is now possible to compile io.js for Android and related
devices #1307 (Giovanny Andres Gongora Granada).
f3e9da3
@jasisk
jasisk commented Apr 6, 2015

Hasn't calmed down yet but it's looking really good! I've learned to hold off for a few days—for some reason we've historically seen explosive memory growth on the order of 120mb / day, starting a couple of days in—but can't ask for a better graph so far.

purple: 0.12, blue: 1.x
RSS

@Fishrock123
Member

@jasisk Mind giving an update? :D

@jasisk
jasisk commented Apr 10, 2015

Was subscribing to, "no news is good news." 😀

These two machines are still instrumented to take heap snapshots periodically which is why it's not super clean, however they're acting similarly which makes me think you guys nailed it!

blue: iojs, purple: 0.12
RSS

@indutny
Member
indutny commented Apr 10, 2015

Hooray! I suggest closing the issue then, and reopening it in case of any trouble ;)

@jasisk
jasisk commented Apr 10, 2015

👍

@Fishrock123
Member

Indeed. I'd gone ahead and said this was fixed as we knew in the 1.6.4 release. Closing, hopefully for good! :)

@JCMais
JCMais commented Apr 10, 2015

Congratulations to everyone envolved. I was accompanying this issue, and was one of the best efforts to exterminate memory leaks that I've seen in my short history with open source projects. 👏

@rvagg rvagg added a commit that referenced this issue Apr 14, 2015
@rvagg rvagg 2015-04-14 io.js v1.7.0 Release
Notable changes:

* C++ API: Fedor Indutny contributed a feature to V8 which has been
  backported to the V8 bundled in io.js. SealHandleScope allows a C++
  add-on author to seal a HandleScope to prevent further, unintended
  allocations within it. Currently only enabled for debug builds of
  io.js. This feature helped detect the leak in #1075 and is now
  activated on the root HandleScope in io.js. (Fedor Indutny) #1395.
* ARM: This release includes significant work to improve the state of
  ARM support for builds and tests. The io.js CI cluster's ARMv6,
  ARMv7 and ARMv8 build servers are now all (mostly) reporting passing
  builds and tests.
  - ARMv8 64-bit (AARCH64) is now properly supported, including a
    backported fix in libuv that was mistakenly detecting the
    existence of `epoll_wait()`. (Ben Noordhuis) #1365.
  - ARMv6: #1376 reported a problem with Math.exp() on ARMv6 (incl
    Raspberry Pi). The culprit is erroneous codegen for ARMv6 when
    using the "fast math" feature of V8. --nofast_math has been turned
    on for all ARMv6 variants by default to avoid this, fast math can
    be turned back on with --fast_math. (Ben Noordhuis) #1398.
  - Tests: timeouts have been tuned specifically for slower platforms,
    detected as ARMv6 and ARMv7. (Roman Reiss) #1366.
* npm: Upgrade npm to 2.7.6. See the release notes
  (https://github.com/npm/npm/releases/tag/v2.7.6) for details.
a75149f
@capaj
capaj commented Apr 14, 2015

wow they must love @indutny at google V8 team. Pushing features just so iojs can fix memory leak. Great stuff 👌

@mscreenie

Congrats, your commitment to this problem and enthusiasm is outstanding and infectious. 👍

@indutny
Member
indutny commented Apr 14, 2015

Thanks guys!

@jihchi jihchi referenced this issue in nodejs/nodejs-zh-TW Apr 15, 2015
Merged

翻譯 io.js 3/20 週報 #75

@interstellerS

This thread was exciting to watch as a node/io newbie , inspired by @indutny work . 👍

@gm112
gm112 commented Apr 16, 2015

@devinus probably node-inspector or the blink developer tools

@devinus
devinus commented Apr 16, 2015

@gm112 My first guess was node-inspector, but it doesn't support io.js. I'm not sure how it could be Blink developer tools either.

@gm112
gm112 commented Apr 16, 2015

@devinus You can tell Blink Developer tools to connect to a remote debugging session, though I'm not 100% sure if this is just on v8 or a remote chrome instance. However Node-Inspector has limited support on iojs, some things work and some things don't. But I could be wrong :)

@Olegas
Contributor
Olegas commented Apr 16, 2015

@devinus I think this was a heap snapshot file generated by https://github.com/bnoordhuis/node-heapdump and opened in Chrome Developer Tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment