New issue
Advanced search Search tips

Issue 707597 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Me2MeNativeMessagingHostMain crashes in AtExitManager

Project Member Reported by zijiehe@chromium.org, Apr 2 2017

Issue description

A crash has been detected in Me2MeNativeMessagingHostMain (remoting_native_messaging_host binary) AtExitManager (during exit).

The stack trace is,
 remoting_core.dll!base::debug::BreakDebugger(void)	C++
 remoting_core.dll!logging::LogMessage::~LogMessage(void)	C++
 remoting_core.dll!base::LazyInstanceTraitsBase<class base::win::MessageWindow::WindowClass>::CallDestructor(class base::win::MessageWindow::WindowClass *)	C++
 remoting_core.dll!base::LazyInstance<class base::win::MessageWindow::WindowClass,struct base::internal::DestructorAtExitLazyInstanceTraits<class base::win::MessageWindow::WindowClass> >::OnExit(void *)	C++
 remoting_core.dll!base::internal::Invoker<struct base::internal::BindState<void (*)(void *),void *>,void >::Run(class base::internal::BindStateBase *)	C++
 remoting_core.dll!base::AtExitManager::ProcessCallbacksNow(void)	C++
 remoting_core.dll!base::AtExitManager::~AtExitManager(void)	C++
 remoting_core.dll!remoting::Me2MeNativeMessagingHostMain(int,char * *)	C++

After some draft investigations, MessageWindow::WindowClass::~WindowClass() throws the error at https://goo.gl/nfev7w.
According to the comments,
    // Hitting this DCHECK usually means that some MessageWindow objects were
    // leaked. For example not calling
    // ui::Clipboard::DestroyClipboardForCurrentThread() results in a leaked
    // MessageWindow.
it looks like we may not release the clipboard.
 
Description: Show this description
Owner: joedow@chromium.org
Status: Assigned (was: Untriaged)

Comment 3 by joedow@chromium.org, Apr 13 2017

Status: WontFix (was: Assigned)
I'm not able to repro this problem on a build synced to 59.0.3070.0.  Do you have any repro steps that can consistently trigger it?

There was a change made ~1 month ago to change the singleton dtor pattern which might have exposed a problem (that was possibly fixed after this bug was filed):
https://codereview.chromium.org/273328300

With respect to the clipboard message, I think that is just a generic message (since the class is in base/win", I don't see any calls to create a clipboard in our Me2Me NMH.

Sign in to add a comment