New issue
Advanced search Search tips

Issue 791091 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Potential memory bug in LevelDBWrapper histograms

Project Member Reported by etienneb@chromium.org, Dec 1 2017

Issue description

There 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
 
Cc: anthonyvd@chromium.org
Owner: mek@chromium.org
+mek for triage. 

This stack trace stops making sense @ the BindOnce call that contains PaymentRequest. My guess is that content::LevelDBWrapperImpl::StartCommitTimer is the source of the leak and the compiler is reusing a template instantiation for that BindOnce call, hence the appearance of PaymentRequest types in the template.
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

Comment 3 by mek@chromium.org, Mar 15 2018

Components: Blink>Storage>DOMStorage
Summary: Potential memory bug in LevelDBWrapper histograms (was: Potential memory bug with Chrome Payment)
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.

Comment 4 by pwnall@chromium.org, Jun 20 2018

Status: WontFix (was: Untriaged)
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