Page 1 of 2

Crashing on shutdown

PostPosted: Wed Nov 08, 2017 12:13 pm
by andpad
Hello,

I'm currently having an issue where my test application is crashing on shutdown.

I see the this error in the output window: [1108/084307.327:FATAL:keyed_service_base_factory.cc(56)] Check failed: (sequence_checker_).CalledOnValidSequence().

I'm currently using the CEF binaries from 3.3202.1680.g700054b, which I upgraded from 3.3163.1671.g700dc25. With 3.3163.1671.g700dc25 this issue was not present for me.

Call Stack:
Code: Select all
    libcef.dll!logging::LogMessage::~LogMessage() Line 791   C++
    libcef.dll!KeyedServiceBaseFactory::~KeyedServiceBaseFactory() Line 57   C++
    libcef.dll!KeyedServiceFactory::~KeyedServiceFactory() Line 22   C++
    [External Code]   
    libcef.dll!base::Singleton<extensions::ProcessMapFactory,base::DefaultSingletonTraits<extensions::ProcessMapFactory>,extensions::ProcessMapFactory>::OnExit(void * __formal) Line 283   C++
    libcef.dll!base::internal::Invoker<base::internal::BindState<void (__cdecl*)(void *),void *>,void __cdecl(void)>::RunImpl<void (__cdecl*const &)(void *),std::tuple<void *> const &,0>(void (void *) * const & functor, const std::tuple<void *> & bound, std::integer_sequence<unsigned int,0> __formal) Line 349   C++
    libcef.dll!base::internal::Invoker<base::internal::BindState<void (__cdecl*)(void *),void *>,void __cdecl(void)>::Run(base::internal::BindStateBase * base) Line 331   C++
    libcef.dll!base::AtExitManager::ProcessCallbacksNow() Line 91   C++
    libcef.dll!base::AtExitManager::~AtExitManager() Line 46   C++
    [External Code]   
    libcef.dll!content::ContentMainRunnerImpl::Shutdown() Line 733   C++
    libcef.dll!service_manager::MainShutdown(service_manager::MainParams & params) Line 511   C++
    libcef.dll!CefContext::FinalizeShutdown() Line 542   C++
    libcef.dll!CefContext::Shutdown() Line 436   C++
    libcef.dll!CefShutdown() Line 257   C++
    libcef.dll!cef_shutdown() Line 246   C++
    micefintegration.dll!CefShutdown() Line 238   C++
    micefintegration.dll!MICEF_Shutdown() Line 36   C++
    miceftestdriver.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * szCmdLine, int iCmdShow) Line 95   C++
    [External Code]   


There were a few threads that suggested that we should append the "--disable-extensions" switch. I've tried that and it seems to shutdown fine without an application crash, but with this setting, as soon as the application starts, one (or both) of my browser test windows goes blank. I noticed that one of the subprocesses is crashing soon after the webpages are loaded. At this point I have no clue on how to debug this particular issue.

Miscellaneous info:
OS: Windows 10
Settings: multi_threaded_message_loop = 1
Switches: --enable-media-stream

Any help is appreciated.

Thank you.

Re: Crashing on shutdown

PostPosted: Wed Nov 08, 2017 12:16 pm
by magreenblatt
What content are you loading? Does the problem reproduce with the cefclient sample application?

Re: Crashing on shutdown

PostPosted: Wed Nov 08, 2017 12:51 pm
by andpad
magreenblatt wrote:What content are you loading? Does the problem reproduce with the cefclient sample application?


I have 2 test browser windows where one navigates to http://www.yahoo.com and the other navigates to http://www.aol.com.

No, I have not been able to reproduce it with cefclient.

Re: Crashing on shutdown

PostPosted: Fri Nov 17, 2017 3:13 pm
by callum
I recently updated the (Win/64) version of CEF I build against from 3071 to 3202 and I also see a crash on exit that wasn't there before (or at least, didn't present itself).

I *thought* I'd got all of that straightened out but apparently not.

Nothing changed in the sequence of required steps for shutdown did it ?

Re: Crashing on shutdown

PostPosted: Fri Nov 17, 2017 3:29 pm
by magreenblatt
callum wrote:I recently updated the (Win/64) version of CEF I build against from 3071 to 3202 and I also see a crash on exit that wasn't there before (or at least, didn't present itself).

I *thought* I'd got all of that straightened out but apparently not.

Nothing changed in the sequence of required steps for shutdown did it ?

Shouldn't be. What is the symbolized call stack for your crash?

Re: Crashing on shutdown

PostPosted: Fri Nov 17, 2017 4:21 pm
by callum
Started investigating and getting a symbolized stack to post here when I noticed:

Code: Select all
    if (mBrowserList.empty())
    {
        // TODO: mark this call as only needed if using CEFs message loop and not CefDoMessageLoopWork()
        CefQuitMessageLoop();

        mParent->getCallbackManager()->onRequestExit();
    }


Removing the unnecessary CefQuitMessageLoop(); did the trick and no crash on exit now. Maybe the 3071 code was more tolerant of the bad call or I just got lucky.

Thanks for pointing me in right direction Matt.

Re: Crashing on shutdown

PostPosted: Fri Jan 12, 2018 3:06 pm
by andpad
With version 3.3239.1723.g071d1c1_windows32, my app is triggering a breakpoint and writing "[0112/114357.945:FATAL:keyed_service_base_factory.cc(56)] Check failed: (sequence_checker_).CalledOnValidSequence()" to the logs.

Call Stack:
Code: Select all
    libcef.dll!logging::LogMessage::~LogMessage() Line 791   C++
    libcef.dll!KeyedServiceBaseFactory::~KeyedServiceBaseFactory() Line 57   C++
    libcef.dll!KeyedServiceFactory::~KeyedServiceFactory() Line 22   C++
    [External Code]   
    libcef.dll!base::Singleton<FontPrefChangeNotifierFactory,base::DefaultSingletonTraits<FontPrefChangeNotifierFactory>,FontPrefChangeNotifierFactory>::OnExit(void * __formal) Line 283   C++
    libcef.dll!base::AtExitManager::ProcessCallbacksNow() Line 90   C++
    libcef.dll!base::AtExitManager::~AtExitManager() Line 46   C++
    libcef.dll!std::default_delete<base::AtExitManager>::operator()(base::AtExitManager * _Ptr) Line 2127   C++
    libcef.dll!content::ContentMainRunnerImpl::Shutdown() Line 734   C++
    libcef.dll!service_manager::MainShutdown(service_manager::MainParams & params) Line 511   C++
    libcef.dll!CefContext::FinalizeShutdown() Line 541   C++
    libcef.dll!CefContext::Shutdown() Line 435   C++
    libcef.dll!CefShutdown() Line 257   C++
    libcef.dll!cef_shutdown() Line 248   C++
>   ceftest.dll!CefShutdown() Line 240   C++


I've appended the "--disable-extensions" switch (as this thread suggests: https://bitbucket.org/chromiumembedded/ ... with-multi), but the issue still occurs.

This does not happen with cefclient. However, I'd like to figure out what's going wrong. Any ideas would be helpful. Thanks in advance.

Note: I was previously using binaries from 3.3163.1671.g700dc25_windows32 until I finally decided to upgrade all the way to 3.3239.1723.g071d1c1_windows32. This issue was not occurring with binaries from 3.3163.1671.g700dc25_windows32.

Re: Crashing on shutdown

PostPosted: Tue Jan 16, 2018 4:29 pm
by andpad
Actually, the issue I mentioned above does happen with cefclient using the following command line arguments "--multi-threaded-message-loop --disable-extensions".

Note this is using binaries from 3.3239.1723.g071d1c1_windows32.

Any ideas? Thanks.

Re: Crashing on shutdown

PostPosted: Fri Jan 19, 2018 3:43 am
by ldamis
andpad wrote:Actually, the issue I mentioned above does happen with cefclient using the following command line arguments "--multi-threaded-message-loop --disable-extensions".

Note this is using binaries from 3.3239.1723.g071d1c1_windows32.


I am also building 3.3239.1723.g071d1c1_windows32 (on Visual Studio 2013) and I am experiencing the same behaviour launcing cefclient with command line arguments "--multi-threaded-message-loop --disable-extensions".

This appens only with Debug build; Release build quits gracefully.

Re: Crashing on shutdown

PostPosted: Thu Jan 25, 2018 11:28 am
by Plinker1961
I'm actually seeing the exact same error fire once when exiting cefclient (version 3.3239.1723.g071d1c1_windows32) in the debugger using command-line arguments "--multi-threaded-message-loop --disable-extensions". Without the --disable-extensions option, it fires about 16 times.

Without --multi-threaded-message-loop, this does not happen. Though my understanding is that "--multi-threaded-message-loop" is preferred under Windows.

Any suggested workarounds for this issue?