Memory leaks into v8 shared library (dll) version 4.1.0.3












0















I use Google V8 as shared library in simple application under Windows. Right now, the application just compile JavaScript without execution. Vld shows the memory leaks into v8.dll. These leaks have call stack like these:



c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (3814): v8.dll!v8::internal::Parser::ParseFunctionLiteral() + 0xBD bytes
c:workv84.1.0.3v8srcparser.cc (1060): v8.dll!v8::internal::Parser::ParseLazy() + 0x71 bytes
c:workv84.1.0.3v8srcparser.cc (1000): v8.dll!v8::internal::Parser::ParseLazy() + 0x15 bytes
c:workv84.1.0.3v8srcparser.cc (5125): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (687): v8.dll!v8::internal::GetUnoptimizedCodeCommon() + 0xF bytes
c:workv84.1.0.3v8srccompiler.cc (966): v8.dll!v8::internal::Compiler::GetLazyCode() + 0x15 bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (36): v8.dll!v8::internal::__RT_impl_Runtime_CompileLazy() + 0xF bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (20): v8.dll!v8::internal::Runtime_CompileLazy() + 0x72 bytes

...

c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (957): v8.dll!v8::internal::Parser::DoParseProgram() + 0x10B bytes
c:workv84.1.0.3v8srcparser.cc (861): v8.dll!v8::internal::Parser::ParseProgram() + 0x27 bytes
c:workv84.1.0.3v8srcparser.cc (5131): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (1148): v8.dll!v8::internal::CompileToplevel() + 0x12 bytes
c:workv84.1.0.3v8srccompiler.cc (1338): v8.dll!v8::internal::Compiler::CompileScript() + 0x15 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1448): v8.dll!v8::internal::Genesis::CompileScriptCached() + 0x9E bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1418): v8.dll!v8::internal::Genesis::CompileNative() + 0x64 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1404): v8.dll!v8::internal::Genesis::CompileExperimentalBuiltin()
c:workv84.1.0.3v8srcbootstrapper.cc (2198): v8.dll!v8::internal::Genesis::InstallExperimentalNatives() + 0x19B bytes
c:workv84.1.0.3v8srcbootstrapper.cc (2766): v8.dll!v8::internal::Genesis::Genesis() + 0xD bytes
c:workv84.1.0.3v8srcbootstrapper.cc (351): v8.dll!v8::internal::Bootstrapper::CreateEnvironment() + 0x32 bytes
c:workv84.1.0.3v8srcapi.cc (5229): v8.dll!v8::CreateEnvironment() + 0x34 bytes
c:workv84.1.0.3v8srcapi.cc (5260): v8.dll!v8::Context::New()


May be someone met the same issue before and can help me to find root of these memory leaks into v8 dll to fix it.



Version 3.31.26 of the V8 doesn't have memory leaks like these.



My application is very simple, first of all init v8:



v8::V8::InitializeICU();
auto platform = platform_ptr(v8::platform::CreateDefaultPlatform());
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();


create isolate:



isolate_ = v8::Isolate::New();
v8::HandleScope handle_scope(isolate_);
global_template_ = std::make_unique<js_compilation::global_template_wrapper>(isolate_);


compiling js code:



void js_compilation::compile(const std::string &js_script)
{
v8::Locker locker(isolate_);
v8::Isolate::Scope scope(isolate_);

//Create a stack allocated handle scope
v8::HandleScope handle_scope(isolate_);
v8::TryCatch try_catch(isolate_);

//Create the global template
v8::Local<v8::ObjectTemplate> global_template = v8::ObjectTemplate::New(isolate_);

//Create a context
v8::Local<v8::Context> context = v8::Context::New(isolate_, NULL, global_template);

//Set the context scope
v8::Context::Scope context_scope(context);
v8::Local<v8::Object> global = context->Global();
v8::Local<v8::String> source = v8::String::NewFromUtf8(isolate_, js_script.c_str());

//Compile
auto script = v8::Script::Compile(source);
if (script.IsEmpty())
{
throw std::runtime_error(get_error_string("Compile error: ", isolate_, try_catch));
}
script->Run();

compiled_script_.Reset(isolate_, script->GetUnboundScript());
}


After compiling:



compiled_script_.Reset();
isolate_->Dispose();

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


Compiling script is:



const std::string jsScript = "function test_function() {n" 
" var match = 0;n"
" if (arguments[0] == arguments[1]) {n"
" match = 1;n"
" }n"
" return match;n"
"}nn"

"function JSrepeat(name, repeat) {n"
" var printthis = "";n"
" for (var i = 0; i < repeat; i++) {n"
" printthis += name;n"
" }n"
" return printthis;n"
"}nn"

"function ReturnThis(anything) {n"
" return anything;n"
"}nn"

"function $13625432() {n"
" return "Jimmy";n"
"}n";









share|improve this question

























  • Memory leak detection tools aren't perfect. In any case, I think you'll get a much more precise answer when you ask the Chromium people directly. Be sure to include the javascript that causes the issue when you do.

    – rubenvb
    Nov 22 '18 at 16:23













  • Thank you for the quick reply! I agree with you tool - isn't perfect, boost::test shows memory leaks also.

    – Yurii
    Nov 22 '18 at 16:35













  • It might also be very possible you're doing something wrong with V8... If you don't show us a minimal example displaying this memory leak, no one will be able to help you much.

    – rubenvb
    Nov 22 '18 at 16:56











  • I would run js_compilation::compile, say, 100 times to check whether the memory usage is really growing. It might happen that V8 just caches some things. Also it's a good idea to compare VLD result with some another profiler like Deleaker. VLD may check for leaks before V8 releases all the memory.

    – Artem Razin
    Nov 23 '18 at 16:45


















0















I use Google V8 as shared library in simple application under Windows. Right now, the application just compile JavaScript without execution. Vld shows the memory leaks into v8.dll. These leaks have call stack like these:



c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (3814): v8.dll!v8::internal::Parser::ParseFunctionLiteral() + 0xBD bytes
c:workv84.1.0.3v8srcparser.cc (1060): v8.dll!v8::internal::Parser::ParseLazy() + 0x71 bytes
c:workv84.1.0.3v8srcparser.cc (1000): v8.dll!v8::internal::Parser::ParseLazy() + 0x15 bytes
c:workv84.1.0.3v8srcparser.cc (5125): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (687): v8.dll!v8::internal::GetUnoptimizedCodeCommon() + 0xF bytes
c:workv84.1.0.3v8srccompiler.cc (966): v8.dll!v8::internal::Compiler::GetLazyCode() + 0x15 bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (36): v8.dll!v8::internal::__RT_impl_Runtime_CompileLazy() + 0xF bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (20): v8.dll!v8::internal::Runtime_CompileLazy() + 0x72 bytes

...

c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (957): v8.dll!v8::internal::Parser::DoParseProgram() + 0x10B bytes
c:workv84.1.0.3v8srcparser.cc (861): v8.dll!v8::internal::Parser::ParseProgram() + 0x27 bytes
c:workv84.1.0.3v8srcparser.cc (5131): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (1148): v8.dll!v8::internal::CompileToplevel() + 0x12 bytes
c:workv84.1.0.3v8srccompiler.cc (1338): v8.dll!v8::internal::Compiler::CompileScript() + 0x15 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1448): v8.dll!v8::internal::Genesis::CompileScriptCached() + 0x9E bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1418): v8.dll!v8::internal::Genesis::CompileNative() + 0x64 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1404): v8.dll!v8::internal::Genesis::CompileExperimentalBuiltin()
c:workv84.1.0.3v8srcbootstrapper.cc (2198): v8.dll!v8::internal::Genesis::InstallExperimentalNatives() + 0x19B bytes
c:workv84.1.0.3v8srcbootstrapper.cc (2766): v8.dll!v8::internal::Genesis::Genesis() + 0xD bytes
c:workv84.1.0.3v8srcbootstrapper.cc (351): v8.dll!v8::internal::Bootstrapper::CreateEnvironment() + 0x32 bytes
c:workv84.1.0.3v8srcapi.cc (5229): v8.dll!v8::CreateEnvironment() + 0x34 bytes
c:workv84.1.0.3v8srcapi.cc (5260): v8.dll!v8::Context::New()


May be someone met the same issue before and can help me to find root of these memory leaks into v8 dll to fix it.



Version 3.31.26 of the V8 doesn't have memory leaks like these.



My application is very simple, first of all init v8:



v8::V8::InitializeICU();
auto platform = platform_ptr(v8::platform::CreateDefaultPlatform());
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();


create isolate:



isolate_ = v8::Isolate::New();
v8::HandleScope handle_scope(isolate_);
global_template_ = std::make_unique<js_compilation::global_template_wrapper>(isolate_);


compiling js code:



void js_compilation::compile(const std::string &js_script)
{
v8::Locker locker(isolate_);
v8::Isolate::Scope scope(isolate_);

//Create a stack allocated handle scope
v8::HandleScope handle_scope(isolate_);
v8::TryCatch try_catch(isolate_);

//Create the global template
v8::Local<v8::ObjectTemplate> global_template = v8::ObjectTemplate::New(isolate_);

//Create a context
v8::Local<v8::Context> context = v8::Context::New(isolate_, NULL, global_template);

//Set the context scope
v8::Context::Scope context_scope(context);
v8::Local<v8::Object> global = context->Global();
v8::Local<v8::String> source = v8::String::NewFromUtf8(isolate_, js_script.c_str());

//Compile
auto script = v8::Script::Compile(source);
if (script.IsEmpty())
{
throw std::runtime_error(get_error_string("Compile error: ", isolate_, try_catch));
}
script->Run();

compiled_script_.Reset(isolate_, script->GetUnboundScript());
}


After compiling:



compiled_script_.Reset();
isolate_->Dispose();

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


Compiling script is:



const std::string jsScript = "function test_function() {n" 
" var match = 0;n"
" if (arguments[0] == arguments[1]) {n"
" match = 1;n"
" }n"
" return match;n"
"}nn"

"function JSrepeat(name, repeat) {n"
" var printthis = "";n"
" for (var i = 0; i < repeat; i++) {n"
" printthis += name;n"
" }n"
" return printthis;n"
"}nn"

"function ReturnThis(anything) {n"
" return anything;n"
"}nn"

"function $13625432() {n"
" return "Jimmy";n"
"}n";









share|improve this question

























  • Memory leak detection tools aren't perfect. In any case, I think you'll get a much more precise answer when you ask the Chromium people directly. Be sure to include the javascript that causes the issue when you do.

    – rubenvb
    Nov 22 '18 at 16:23













  • Thank you for the quick reply! I agree with you tool - isn't perfect, boost::test shows memory leaks also.

    – Yurii
    Nov 22 '18 at 16:35













  • It might also be very possible you're doing something wrong with V8... If you don't show us a minimal example displaying this memory leak, no one will be able to help you much.

    – rubenvb
    Nov 22 '18 at 16:56











  • I would run js_compilation::compile, say, 100 times to check whether the memory usage is really growing. It might happen that V8 just caches some things. Also it's a good idea to compare VLD result with some another profiler like Deleaker. VLD may check for leaks before V8 releases all the memory.

    – Artem Razin
    Nov 23 '18 at 16:45
















0












0








0








I use Google V8 as shared library in simple application under Windows. Right now, the application just compile JavaScript without execution. Vld shows the memory leaks into v8.dll. These leaks have call stack like these:



c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (3814): v8.dll!v8::internal::Parser::ParseFunctionLiteral() + 0xBD bytes
c:workv84.1.0.3v8srcparser.cc (1060): v8.dll!v8::internal::Parser::ParseLazy() + 0x71 bytes
c:workv84.1.0.3v8srcparser.cc (1000): v8.dll!v8::internal::Parser::ParseLazy() + 0x15 bytes
c:workv84.1.0.3v8srcparser.cc (5125): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (687): v8.dll!v8::internal::GetUnoptimizedCodeCommon() + 0xF bytes
c:workv84.1.0.3v8srccompiler.cc (966): v8.dll!v8::internal::Compiler::GetLazyCode() + 0x15 bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (36): v8.dll!v8::internal::__RT_impl_Runtime_CompileLazy() + 0xF bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (20): v8.dll!v8::internal::Runtime_CompileLazy() + 0x72 bytes

...

c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (957): v8.dll!v8::internal::Parser::DoParseProgram() + 0x10B bytes
c:workv84.1.0.3v8srcparser.cc (861): v8.dll!v8::internal::Parser::ParseProgram() + 0x27 bytes
c:workv84.1.0.3v8srcparser.cc (5131): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (1148): v8.dll!v8::internal::CompileToplevel() + 0x12 bytes
c:workv84.1.0.3v8srccompiler.cc (1338): v8.dll!v8::internal::Compiler::CompileScript() + 0x15 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1448): v8.dll!v8::internal::Genesis::CompileScriptCached() + 0x9E bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1418): v8.dll!v8::internal::Genesis::CompileNative() + 0x64 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1404): v8.dll!v8::internal::Genesis::CompileExperimentalBuiltin()
c:workv84.1.0.3v8srcbootstrapper.cc (2198): v8.dll!v8::internal::Genesis::InstallExperimentalNatives() + 0x19B bytes
c:workv84.1.0.3v8srcbootstrapper.cc (2766): v8.dll!v8::internal::Genesis::Genesis() + 0xD bytes
c:workv84.1.0.3v8srcbootstrapper.cc (351): v8.dll!v8::internal::Bootstrapper::CreateEnvironment() + 0x32 bytes
c:workv84.1.0.3v8srcapi.cc (5229): v8.dll!v8::CreateEnvironment() + 0x34 bytes
c:workv84.1.0.3v8srcapi.cc (5260): v8.dll!v8::Context::New()


May be someone met the same issue before and can help me to find root of these memory leaks into v8 dll to fix it.



Version 3.31.26 of the V8 doesn't have memory leaks like these.



My application is very simple, first of all init v8:



v8::V8::InitializeICU();
auto platform = platform_ptr(v8::platform::CreateDefaultPlatform());
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();


create isolate:



isolate_ = v8::Isolate::New();
v8::HandleScope handle_scope(isolate_);
global_template_ = std::make_unique<js_compilation::global_template_wrapper>(isolate_);


compiling js code:



void js_compilation::compile(const std::string &js_script)
{
v8::Locker locker(isolate_);
v8::Isolate::Scope scope(isolate_);

//Create a stack allocated handle scope
v8::HandleScope handle_scope(isolate_);
v8::TryCatch try_catch(isolate_);

//Create the global template
v8::Local<v8::ObjectTemplate> global_template = v8::ObjectTemplate::New(isolate_);

//Create a context
v8::Local<v8::Context> context = v8::Context::New(isolate_, NULL, global_template);

//Set the context scope
v8::Context::Scope context_scope(context);
v8::Local<v8::Object> global = context->Global();
v8::Local<v8::String> source = v8::String::NewFromUtf8(isolate_, js_script.c_str());

//Compile
auto script = v8::Script::Compile(source);
if (script.IsEmpty())
{
throw std::runtime_error(get_error_string("Compile error: ", isolate_, try_catch));
}
script->Run();

compiled_script_.Reset(isolate_, script->GetUnboundScript());
}


After compiling:



compiled_script_.Reset();
isolate_->Dispose();

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


Compiling script is:



const std::string jsScript = "function test_function() {n" 
" var match = 0;n"
" if (arguments[0] == arguments[1]) {n"
" match = 1;n"
" }n"
" return match;n"
"}nn"

"function JSrepeat(name, repeat) {n"
" var printthis = "";n"
" for (var i = 0; i < repeat; i++) {n"
" printthis += name;n"
" }n"
" return printthis;n"
"}nn"

"function ReturnThis(anything) {n"
" return anything;n"
"}nn"

"function $13625432() {n"
" return "Jimmy";n"
"}n";









share|improve this question
















I use Google V8 as shared library in simple application under Windows. Right now, the application just compile JavaScript without execution. Vld shows the memory leaks into v8.dll. These leaks have call stack like these:



c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (3814): v8.dll!v8::internal::Parser::ParseFunctionLiteral() + 0xBD bytes
c:workv84.1.0.3v8srcparser.cc (1060): v8.dll!v8::internal::Parser::ParseLazy() + 0x71 bytes
c:workv84.1.0.3v8srcparser.cc (1000): v8.dll!v8::internal::Parser::ParseLazy() + 0x15 bytes
c:workv84.1.0.3v8srcparser.cc (5125): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (687): v8.dll!v8::internal::GetUnoptimizedCodeCommon() + 0xF bytes
c:workv84.1.0.3v8srccompiler.cc (966): v8.dll!v8::internal::Compiler::GetLazyCode() + 0x15 bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (36): v8.dll!v8::internal::__RT_impl_Runtime_CompileLazy() + 0xF bytes
c:workv84.1.0.3v8srcruntimeruntime-compiler.cc (20): v8.dll!v8::internal::Runtime_CompileLazy() + 0x72 bytes

...

c:program files (x86)microsoft visual studio 14.0vcincludexmemory0 (977): v8.dll!std::_Wrap_alloc<std::allocator<std::_Container_proxy> >::allocate()
c:program files (x86)microsoft visual studio 14.0vcincludevector (580): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Alloc_proxy() + 0xF bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (545): v8.dll!std::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >::_Vector_alloc<std::_Vec_base_types<unsigned char,std::allocator<unsigned char> > >() + 0xA bytes
c:program files (x86)microsoft visual studio 14.0vcincludevector (706): v8.dll!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> >() + 0xA bytes
c:workv84.1.0.3v8srctype-feedback-vector.h (21): v8.dll!v8::internal::FeedbackVectorSpec::FeedbackVectorSpec() + 0x31 bytes
c:workv84.1.0.3v8srcast.h (175): v8.dll!v8::internal::AstProperties::AstProperties() + 0x33 bytes
c:workv84.1.0.3v8srcast.h (2607): v8.dll!v8::internal::FunctionLiteral::FunctionLiteral() + 0x22 bytes
c:workv84.1.0.3v8srcast.h (3515): v8.dll!v8::internal::AstNodeFactory::NewFunctionLiteral() + 0xDC bytes
c:workv84.1.0.3v8srcparser.cc (957): v8.dll!v8::internal::Parser::DoParseProgram() + 0x10B bytes
c:workv84.1.0.3v8srcparser.cc (861): v8.dll!v8::internal::Parser::ParseProgram() + 0x27 bytes
c:workv84.1.0.3v8srcparser.cc (5131): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srcparser.h (673): v8.dll!v8::internal::Parser::Parse() + 0xA bytes
c:workv84.1.0.3v8srccompiler.cc (1148): v8.dll!v8::internal::CompileToplevel() + 0x12 bytes
c:workv84.1.0.3v8srccompiler.cc (1338): v8.dll!v8::internal::Compiler::CompileScript() + 0x15 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1448): v8.dll!v8::internal::Genesis::CompileScriptCached() + 0x9E bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1418): v8.dll!v8::internal::Genesis::CompileNative() + 0x64 bytes
c:workv84.1.0.3v8srcbootstrapper.cc (1404): v8.dll!v8::internal::Genesis::CompileExperimentalBuiltin()
c:workv84.1.0.3v8srcbootstrapper.cc (2198): v8.dll!v8::internal::Genesis::InstallExperimentalNatives() + 0x19B bytes
c:workv84.1.0.3v8srcbootstrapper.cc (2766): v8.dll!v8::internal::Genesis::Genesis() + 0xD bytes
c:workv84.1.0.3v8srcbootstrapper.cc (351): v8.dll!v8::internal::Bootstrapper::CreateEnvironment() + 0x32 bytes
c:workv84.1.0.3v8srcapi.cc (5229): v8.dll!v8::CreateEnvironment() + 0x34 bytes
c:workv84.1.0.3v8srcapi.cc (5260): v8.dll!v8::Context::New()


May be someone met the same issue before and can help me to find root of these memory leaks into v8 dll to fix it.



Version 3.31.26 of the V8 doesn't have memory leaks like these.



My application is very simple, first of all init v8:



v8::V8::InitializeICU();
auto platform = platform_ptr(v8::platform::CreateDefaultPlatform());
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();


create isolate:



isolate_ = v8::Isolate::New();
v8::HandleScope handle_scope(isolate_);
global_template_ = std::make_unique<js_compilation::global_template_wrapper>(isolate_);


compiling js code:



void js_compilation::compile(const std::string &js_script)
{
v8::Locker locker(isolate_);
v8::Isolate::Scope scope(isolate_);

//Create a stack allocated handle scope
v8::HandleScope handle_scope(isolate_);
v8::TryCatch try_catch(isolate_);

//Create the global template
v8::Local<v8::ObjectTemplate> global_template = v8::ObjectTemplate::New(isolate_);

//Create a context
v8::Local<v8::Context> context = v8::Context::New(isolate_, NULL, global_template);

//Set the context scope
v8::Context::Scope context_scope(context);
v8::Local<v8::Object> global = context->Global();
v8::Local<v8::String> source = v8::String::NewFromUtf8(isolate_, js_script.c_str());

//Compile
auto script = v8::Script::Compile(source);
if (script.IsEmpty())
{
throw std::runtime_error(get_error_string("Compile error: ", isolate_, try_catch));
}
script->Run();

compiled_script_.Reset(isolate_, script->GetUnboundScript());
}


After compiling:



compiled_script_.Reset();
isolate_->Dispose();

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


Compiling script is:



const std::string jsScript = "function test_function() {n" 
" var match = 0;n"
" if (arguments[0] == arguments[1]) {n"
" match = 1;n"
" }n"
" return match;n"
"}nn"

"function JSrepeat(name, repeat) {n"
" var printthis = "";n"
" for (var i = 0; i < repeat; i++) {n"
" printthis += name;n"
" }n"
" return printthis;n"
"}nn"

"function ReturnThis(anything) {n"
" return anything;n"
"}nn"

"function $13625432() {n"
" return "Jimmy";n"
"}n";






c++ memory-leaks v8






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 22 '18 at 17:30







Yurii

















asked Nov 22 '18 at 16:14









YuriiYurii

12




12













  • Memory leak detection tools aren't perfect. In any case, I think you'll get a much more precise answer when you ask the Chromium people directly. Be sure to include the javascript that causes the issue when you do.

    – rubenvb
    Nov 22 '18 at 16:23













  • Thank you for the quick reply! I agree with you tool - isn't perfect, boost::test shows memory leaks also.

    – Yurii
    Nov 22 '18 at 16:35













  • It might also be very possible you're doing something wrong with V8... If you don't show us a minimal example displaying this memory leak, no one will be able to help you much.

    – rubenvb
    Nov 22 '18 at 16:56











  • I would run js_compilation::compile, say, 100 times to check whether the memory usage is really growing. It might happen that V8 just caches some things. Also it's a good idea to compare VLD result with some another profiler like Deleaker. VLD may check for leaks before V8 releases all the memory.

    – Artem Razin
    Nov 23 '18 at 16:45





















  • Memory leak detection tools aren't perfect. In any case, I think you'll get a much more precise answer when you ask the Chromium people directly. Be sure to include the javascript that causes the issue when you do.

    – rubenvb
    Nov 22 '18 at 16:23













  • Thank you for the quick reply! I agree with you tool - isn't perfect, boost::test shows memory leaks also.

    – Yurii
    Nov 22 '18 at 16:35













  • It might also be very possible you're doing something wrong with V8... If you don't show us a minimal example displaying this memory leak, no one will be able to help you much.

    – rubenvb
    Nov 22 '18 at 16:56











  • I would run js_compilation::compile, say, 100 times to check whether the memory usage is really growing. It might happen that V8 just caches some things. Also it's a good idea to compare VLD result with some another profiler like Deleaker. VLD may check for leaks before V8 releases all the memory.

    – Artem Razin
    Nov 23 '18 at 16:45



















Memory leak detection tools aren't perfect. In any case, I think you'll get a much more precise answer when you ask the Chromium people directly. Be sure to include the javascript that causes the issue when you do.

– rubenvb
Nov 22 '18 at 16:23







Memory leak detection tools aren't perfect. In any case, I think you'll get a much more precise answer when you ask the Chromium people directly. Be sure to include the javascript that causes the issue when you do.

– rubenvb
Nov 22 '18 at 16:23















Thank you for the quick reply! I agree with you tool - isn't perfect, boost::test shows memory leaks also.

– Yurii
Nov 22 '18 at 16:35







Thank you for the quick reply! I agree with you tool - isn't perfect, boost::test shows memory leaks also.

– Yurii
Nov 22 '18 at 16:35















It might also be very possible you're doing something wrong with V8... If you don't show us a minimal example displaying this memory leak, no one will be able to help you much.

– rubenvb
Nov 22 '18 at 16:56





It might also be very possible you're doing something wrong with V8... If you don't show us a minimal example displaying this memory leak, no one will be able to help you much.

– rubenvb
Nov 22 '18 at 16:56













I would run js_compilation::compile, say, 100 times to check whether the memory usage is really growing. It might happen that V8 just caches some things. Also it's a good idea to compare VLD result with some another profiler like Deleaker. VLD may check for leaks before V8 releases all the memory.

– Artem Razin
Nov 23 '18 at 16:45







I would run js_compilation::compile, say, 100 times to check whether the memory usage is really growing. It might happen that V8 just caches some things. Also it's a good idea to compare VLD result with some another profiler like Deleaker. VLD may check for leaks before V8 releases all the memory.

– Artem Razin
Nov 23 '18 at 16:45














1 Answer
1






active

oldest

votes


















0














V8 developer here. Version 4.1.0.3 is ancient and was never considered particularly stable (.3 is right after a branch point, not the end of a stable branch, so it's almost like any random daily snapshot). If you can reproduce these issues with version 7.0.276.40 (or later) I'd be interested to take a closer look, but versions 4.x are just not worth anyone's time at this point, sorry.






share|improve this answer
























  • Valgrind shows no memory leaks for the last version of v8 (7.2). Also vld shows some memory leaks which can be ignored under windows for the same v8 version. So we can say the last version doesn't have memory leaks.

    – Yurii
    Nov 27 '18 at 8:38











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434838%2fmemory-leaks-into-v8-shared-library-dll-version-4-1-0-3%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














V8 developer here. Version 4.1.0.3 is ancient and was never considered particularly stable (.3 is right after a branch point, not the end of a stable branch, so it's almost like any random daily snapshot). If you can reproduce these issues with version 7.0.276.40 (or later) I'd be interested to take a closer look, but versions 4.x are just not worth anyone's time at this point, sorry.






share|improve this answer
























  • Valgrind shows no memory leaks for the last version of v8 (7.2). Also vld shows some memory leaks which can be ignored under windows for the same v8 version. So we can say the last version doesn't have memory leaks.

    – Yurii
    Nov 27 '18 at 8:38
















0














V8 developer here. Version 4.1.0.3 is ancient and was never considered particularly stable (.3 is right after a branch point, not the end of a stable branch, so it's almost like any random daily snapshot). If you can reproduce these issues with version 7.0.276.40 (or later) I'd be interested to take a closer look, but versions 4.x are just not worth anyone's time at this point, sorry.






share|improve this answer
























  • Valgrind shows no memory leaks for the last version of v8 (7.2). Also vld shows some memory leaks which can be ignored under windows for the same v8 version. So we can say the last version doesn't have memory leaks.

    – Yurii
    Nov 27 '18 at 8:38














0












0








0







V8 developer here. Version 4.1.0.3 is ancient and was never considered particularly stable (.3 is right after a branch point, not the end of a stable branch, so it's almost like any random daily snapshot). If you can reproduce these issues with version 7.0.276.40 (or later) I'd be interested to take a closer look, but versions 4.x are just not worth anyone's time at this point, sorry.






share|improve this answer













V8 developer here. Version 4.1.0.3 is ancient and was never considered particularly stable (.3 is right after a branch point, not the end of a stable branch, so it's almost like any random daily snapshot). If you can reproduce these issues with version 7.0.276.40 (or later) I'd be interested to take a closer look, but versions 4.x are just not worth anyone's time at this point, sorry.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 24 '18 at 8:05









jmrkjmrk

6,288928




6,288928













  • Valgrind shows no memory leaks for the last version of v8 (7.2). Also vld shows some memory leaks which can be ignored under windows for the same v8 version. So we can say the last version doesn't have memory leaks.

    – Yurii
    Nov 27 '18 at 8:38



















  • Valgrind shows no memory leaks for the last version of v8 (7.2). Also vld shows some memory leaks which can be ignored under windows for the same v8 version. So we can say the last version doesn't have memory leaks.

    – Yurii
    Nov 27 '18 at 8:38

















Valgrind shows no memory leaks for the last version of v8 (7.2). Also vld shows some memory leaks which can be ignored under windows for the same v8 version. So we can say the last version doesn't have memory leaks.

– Yurii
Nov 27 '18 at 8:38





Valgrind shows no memory leaks for the last version of v8 (7.2). Also vld shows some memory leaks which can be ignored under windows for the same v8 version. So we can say the last version doesn't have memory leaks.

– Yurii
Nov 27 '18 at 8:38




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434838%2fmemory-leaks-into-v8-shared-library-dll-version-4-1-0-3%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]