I need some help understanding this call stack. The resize results in a 47MB allocation that never gets freed. This happened twice during a 6 hour run.
StackTrace Content v8director!v8::internal::List<v8::internal::Code *,v8::internal::FreeStoreAllocationPolicy>::Resize+22 bytes, 0xE6BF76 v8director!v8::Context::Enter+199 bytes, 0xE1F2D7 v8director!`anonymous namespace'::DecoupledCall::call v8director! boost::asio::detail::completion_handler<boost::_bi::bind_t<void,boost::_mfi::mf0<void,`anonymous DecoupledCall is making a synchronous (no locks) call into V8 using previously stored persistent handles to a function and parameters. I have seen this leak occur twice with this stack, but is exceptionally rare; two times over thousands and thousands of iterations. I would love to learn that it is related to this stack, but I suspect it's a coincidence. The parameter v8::internal::Code suggests this is an allocation for code. Why would V8 suddenly need 50MB of code storage after running the same thing for 6 hours? What am I seeing? Could a closure cause this? Would any logging help? Stuart. -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
