Memory leaks into v8 shared library (dll) version 4.1.0.3
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
add a comment |
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
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 runjs_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
add a comment |
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
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
c++ memory-leaks v8
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 runjs_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
add a comment |
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 runjs_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
add a comment |
1 Answer
1
active
oldest
votes
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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