Isolate destruction "leaking" memory ?

[YJ]

Kinda related to this old thread https://groups.google.com/forum/#!searchin/v8-users/isolate$20memory|sort:date/v8-users/C_CzX8nSbDU/c4FR8-j6BQAJ

Basically, I'd imagine if I instantiate an isolate and immediately "Dispose" it inside a loop, all memory used by the isolated should be released therefore the loop could go on forever. In reality however, doing this would consume all available memories and doesn't seem to release any memory back to the os at all. It is not a "leak" in the sense that it can be caught by valgrind, it appears something is actually hogging the memory. I am really curious of what is holding onto the memory. I really hope I am just missing something obvious and any help is appreciated.

I test the following code on a MBP

#include "v8/include/v8.h"

#include "v8/include/libplatform/libplatform.h"

int main(int argc, char* argv[]) {

  v8::V8::InitializeICUDefaultLocation(V8_LIB_FULL_PATH);

  v8::V8::InitializeExternalStartupData(V8_LIB_FULL_PATH);

  std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();

  v8::V8::InitializePlatform(platform.get());

  v8::V8::Initialize();

  for (auto i = 0; i < 1000000000; ++i) {

    v8::Isolate::CreateParams create_params;

    create_params.array_buffer_allocator = v8::ArrayBuffer::Allocator::NewDefaultAllocator();

    v8::Isolate* isolate = v8::Isolate::New(create_params);

    isolate->Dispose();

    delete create_params.array_buffer_allocator;

  }

  v8::V8::Dispose();

  v8::V8::ShutdownPlatform();

}

It will run until all memory is gone and macOS will just be unresponsive.

I was using v8 version 6.5 and with the following build args

is_debug = false

target_cpu = "x64"

use_drfuzz = false

use_libfuzzer = false

v8_enable_test_features = ""

v8_experimental_extra_library_files = []

v8_extra_library_files = []

symbol_level = 1

is_component_build = false

use_sysroot = false

use_glib = false

use_custom_libcxx = false

use_custom_libcxx_for_host = false

v8_enable_i18n_support = false

icu_use_data_file = false

v8_static_library = true

v8_enable_gdbjit = false

Thanks

[Jakob Kummerow]

One obvious observation is that you don't have a delete isolate; statement in the loop ;-)

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jakob Kummerow]

Never mind; that shouldn't be needed, as isolate->Dispose() contains delete this. Funky!

You said "it can be caught by valgrind". What does Valgrind report?

[YJ]

Hi Jakob,

I meant it is NOT something is caught by valgrind.

I cannot get valgrind to work on my mac running sierra. But on linux valgrind finds no concrete leak with the program. By changing the loop iteration count, valgrind always gives the same results.

[David]

Hi YJ,

I have the exact same problem (without the loop).

Did you find how fix this memory leaks ?

Thanks in advance pour your help

Ps I use V8 7.1.302.33 with visual studio 2017 under Windows

[YJ]

Hey David,

Unfortunately no, I didn't find any resolution. I figured it is not a typical use case to keep spawning new isolates. I ended up re-using isolates, which luckily worked fine for me.

And to be honest while I used the term "leak", it might not be one. It might be a fragmentation problem or something.

Hope this helps.

[David]

oh damn....

In fact, I have the leak with the hello world https://github.com/v8/v8/blob/master/samples/hello-world.cc .

So I thing this isn't normal.

The minimal code which reproduce the problem is just

int main(int argc, char* argv[])
{

    // V8 version 7.1.302.33
    v8::V8::InitializeICUDefaultLocation(argv[0]);
    v8::V8::InitializeExternalStartupData(argv[0]);

    std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
    v8::V8::InitializePlatform(platform.get());
    v8::V8::Initialize();

    v8::Isolate::CreateParams create_params;

    create_params.array_buffer_allocator = v8::ArrayBuffer::Allocator::NewDefaultAllocator();

    v8::Isolate* pIsolate = v8::Isolate::New(create_params); // If I remove this line and the next one, memory leak disappears
    pIsolate->Dispose();

    v8::V8::Dispose();
    v8::V8::ShutdownPlatform();

    delete create_params.array_buffer_allocator;
}

[Giovanni Chiocchio]

anyone have used new workerthread in nodejs? I suspect it have the same problem because I have see an abnormal use of memory if I call many time new Worker  with simple script.

[Giovanni Chiocchio]

Only method that work for my code is force garbage collector with LowMemoryNotification before dispose.

[Vinayaka Kamath]

Hello All,

LSan is detecting this as a memory leak in version 8.3. Did anyone else find a concrete solution? I tried forcing GC with LowMemoryNotification, that approach doesn't work for some reason.

[YJ]

Also still curious if there is any good solution to this. Vinay do you mind report a bug to https://bugs.chromium.org/p/v8/issues/entry along with the LSan results?

While re-using isolates as much as possible is okay, it is a kind of a dilemma because there are other conditions that may force the use of a new isolate.