New issue
Advanced search Search tips

Issue 813951 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

app_shell DCHECKs on exit with --disable-gpu

Project Member Reported by michae...@chromium.org, Feb 20 2018

Issue description

app_shell is an app runner, much like content_shell but for apps.

It DCHECKs on exit when --disable-gpu is specified (or when no GPU is available):

[136857:136865:0220/145637.889518:2732813702562:WARNING:discardable_shared_memory_manager.cc(436)] Some MojoDiscardableSharedMemoryManagerImpls are still alive. They will be leaked.
[136857:136857:0220/145637.893463:2732813706505:FATAL:server_shared_bitmap_manager.cc(71)] Check failed: handle_map_.empty().
#0 0x7f6056dcb54c base::debug::StackTrace::StackTrace()
#1 0x7f6056df578b logging::LogMessage::~LogMessage()
#2 0x7f604d53bdf8 viz::ServerSharedBitmapManager::~ServerSharedBitmapManager()
#3 0x7f604d53cf41 base::LazyInstance<>::OnExit()
#4 0x7f6056db683a base::AtExitManager::ProcessCallbacksNow()
#5 0x7f6056db65d5 base::AtExitManager::~AtExitManager()
#6 0x7f60565c51d1 content::ContentMainRunnerImpl::Shutdown()
#7 0x7f604c9de9d9 service_manager::Main()
#8 0x7f60565c3381 content::ContentMain()
#9 0x000000423151 main
#10 0x7f604dafff45 __libc_start_main
#11 0x00000042302a _start


Seems like some shared memory is not being freed. I suspect this is due to a larger problem in how app_shell starts up or exits, because I'm sure there are things content_shell does that app_shell doesn't.

To start investigating, I'm not sure if the issue really has to do with viz or mojo. I've CC'd some folks who might be knowledgeable -- can anyone provide any pointers?
 

Comment 1 by danakj@chromium.org, Feb 21 2018

I think the Mojo warning and the DCHECK are separate things.

I think this either
A) a layer compositor (cc::LayerTreeHost) or some other viz client is not destroyed, so it's holding shared bitmaps alive.
B) above client is destroyed but the notifications are still in flight

Waiting for B doesn't seem useful. I don't think there's a good reason to even destroy the ServerSharedBitmapManager.. maybe it should be a Leaky lazyinstance?

Comment 2 by danakj@chromium.org, Feb 21 2018

FWIW ServerSharedBitmapManager will move to be a non-global variable at some point, I guess the DCHECK would come back then as it would be destroyed as part of BrowserMainThread, or FrameSinkManagerImpl. So removing the DCHECK as well since it's not going to be destroyed if it's leaky would seem pragmatic.
Components: Platform>Apps>Shell
Owner: ----
Status: Available (was: Assigned)

Sign in to add a comment