Thank you, I'll take a look. Stuart.
On Sep 2, 10:29 am, Vyacheslav Egorov <[email protected]> wrote: > Hi, > > I have found only one instantiation of the List<T,P> template with > T=Code* and P=FreeStoreAllocationPolicy it type alias --- CodeList > (see list.h). > > The only instance of the CodeList I could find is allocated on the > stack (see KeyedIC::ComputeStub) and should not leak. > > But this interpretation does not fit your trace. So I think we can > assume that compiler merged some template methods together and it's > either > > List<Handle<Object> > entered_contexts_; or List<Context*> saved_contexts_; > > that get resized when you perform Context::Enter. > > My guess would be that you have unbalanced Context::Enter and > Context::Exit so your stacks of entered/saved contexts grow without > bounds. > > Please check that they are balanced. You can also add some debug > prints into Context::Enter to see length of entered_contexts_ stack. > > -- > Vyacheslav Egorov > > > > On Fri, Sep 2, 2011 at 4:09 PM, Stuart <[email protected]> wrote: > > The system is still running and has since allocated 2 x 150MB more > > using > > v8::internal::List<v8::internal::Code*,v8::internal::FreeStoreAllocationPol > > icy>::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 -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
