Potential memory bug in LevelDBWrapper histograms |
|||
Issue descriptionThere is a potential memory leak that worth investigating. It's related to: payments::PaymentRequestState We received a slow-reports showing 331709 lives objects. We are seeing a potential memory leaks with the following stackframe: base::debug::StackTrace::StackTrace(unsigned int) profiling::AllocatorShimLogAlloc(profiling::AllocatorType,void *,unsigned int,char const *) profiling::`anonymous namespace'::HookAlloc malloc operator new(unsigned int) base::BindOnce<void ( payments::PaymentRequestState::*)(void),base::WeakPtr<payments::PaymentRequestState> >(void ( payments::PaymentRequestState::*&&)(void),base::WeakPtr<payments::PaymentRequestState> &&) content::LevelDBWrapperImpl::StartCommitTimer() base::internal::InvokeHelper<1,void>::MakeItSo<void ( subresource_filter::RulesetService::*const &)(void),base::WeakPtr<subresource_filter::RulesetService> const &>(void ( subresource_filter::RulesetService::*const &)(void),base::WeakPtr<subresource_filter::RulesetService> const &) base::internal::Invoker<base::internal::BindState<void ( subresource_filter::RulesetService::*)(void),base::WeakPtr<subresource_filter::RulesetService> >,void >::Run(base::internal::BindStateBase *) base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *) base::MessageLoop::RunTask(base::PendingTask *) base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) base::MessageLoop::DoWork() base::MessagePumpForIO::DoRunLoop() base::MessagePumpWin::Run(base::MessagePump::Delegate *) base::RunLoop::Run() base::Thread::Run(base::RunLoop *) content::BrowserThreadImpl::IOThreadRun(base::RunLoop *) content::BrowserThreadImpl::Run(base::RunLoop *) base::Thread::ThreadMain() base::`anonymous namespace'::ThreadFunc
,
Dec 1 2017
Here is a bunch of crashid with reporting that stackframe: 438d18443df603a1, 90fa0f3a6be55d5b, 880a48a2f805e499, b6878e3524ba543b, e5764a7926f45a61, f330f35038955cb0, e8fd868d2a8923bc, 66ffd20399593630, bf1c5fa24c49db1d, df8844f28134a705, 78b96780d488ca5d, 787368b61f90b325, d9304a92922c6116, beaf8bb58be0c447, f4a038107d9e7b0a, e8df70711fadaa94, 4311699ca00ee2f3, 37b943fa8f3dae10, eebd5968166e5e29 I looked to 3 of them and Malloc was: 1) 715 M 2) 1,016 M 3) 1,251 M Which is a way above the average. So far, I only got report from that version: 63.0.3239.1 Which may be explain by 1) The bug got fixed 2) The compiler was doing a optimisation and we incorrectly report that bug
,
Mar 15 2018
Sorry for not looking at this earlier. The only thing that StartCommitTimer plausibly allocates would be the histogram it records. Looking at random recent crash reports with StartCommitTimer in the stack trace, it also seems like the vast majority are crashing inside the histogram code, but no idea if or how that is related.
,
Jun 20 2018
I tried out some of the crashes and they don't exist anymore. The Chrome version also looks really old. Let's discuss in a new bug if this is still a problem. |
|||
►
Sign in to add a comment |
|||
Comment 1 by anthonyvd@chromium.org
, Dec 1 2017Owner: mek@chromium.org