The system is still running and has since allocated 2 x 150MB more using v8::internal::List<v8::internal::Code*,v8::internal::FreeStoreAllocationPolicy>::Resize
The stack profile is similar; calling back into V8 using stored function and parameter handles. Any clues? Am I even correct in assuming this has been allocated for code and not data? Stuart. > *,v8::internal::FreeStoreAllocationPolicy>::Resize On Aug 31, 10:46 pm, Stuart <[email protected]> wrote: > 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
