Still Debugging shutdown crash, ghost CefBrowser

Having problems with building or using CEF? This forum is here to help. Please do not post bug reports or feature requests here.

Still Debugging shutdown crash, ghost CefBrowser

Postby richeakin » Mon Feb 03, 2014 5:02 pm

Hello,

I asked a question a while back about why, when I've only created one CefBrowser, my CefClient::OnBeforeClose() close gets called twice at shutdown. Actually, it gets called once when I am about to shutdown and I issue a CloseBrowser(), and then again from ParentWindowWillClose(), although there is no CefBrowser left that I am aware of. Is this explainable?

Reason I'm asking is that I am still trying again to fix this shutdown crash that I have not been able to solve, which appears to be leftover stale CefBrowser references somewhere. However, I am closing all of mine as prescribed by the docs for CefLifespanHandler::DoClose().

Thanks,
Rich
richeakin
Techie
 
Posts: 21
Joined: Mon Dec 16, 2013 11:50 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby magreenblatt » Mon Feb 03, 2014 6:17 pm

richeakin wrote:I asked a question a while back about why, when I've only created one CefBrowser, my CefClient::OnBeforeClose() close gets called twice at shutdown. Actually, it gets called once when I am about to shutdown and I issue a CloseBrowser(), and then again from ParentWindowWillClose(), although there is no CefBrowser left that I am aware of. Is this explainable?

If you're still using 3.1547.1412 then you might want to try with a newer version. If the problem still occurs with the 1650 or newer branch then please run in a debugger with debug symbols loaded and post stack traces for the two calls to OnBeforeClose. ParentWindowWillClose does nothing in CEF3, so it shouldn't be the source of any OnBeforeClose calls.
magreenblatt
Site Admin
 
Posts: 7982
Joined: Fri May 29, 2009 6:57 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby richeakin » Tue Feb 04, 2014 4:44 pm

I'm on 3.1650 now, upgraded when you made the release build (thanks!).

Here's the stacktrace for the first call to OnBeforeClose:

Code: Select all
thread #1: tid = 0x35fdd2, 0x00034c42 Centerstage`cstage::CefClientImpl::OnBeforeClose(this=0x07a51310, browser=0xbfffbe20) + 1666 at CefClientImpl.cpp:80, name = 'CrBrowserMain, queue = 'com.apple.main-thread, stop reason = breakpoint 1.1
    frame #0: 0x00034c42 Centerstage`cstage::CefClientImpl::OnBeforeClose(this=0x07a51310, browser=0xbfffbe20) + 1666 at CefClientImpl.cpp:80
    frame #1: 0x00034d39 Centerstage`_ZThn20_N6cstage13CefClientImpl13OnBeforeCloseE9CefRefPtrI10CefBrowserE(this=0x07a51324, browser=<unavailable>) + 57 at CefClientImpl.cpp:83
    frame #2: 0x005a1732 Centerstage`life_span_handler_on_before_close(self=0x07c39f38, browser=0x07c48d58) + 338 at life_span_handler_cpptoc.cc:191
    frame #3: 0x00f0008f libcef.dylib`CefLifeSpanHandlerCToCpp::OnBeforeClose(this=<unavailable>, browser=<unavailable>) + 239 at life_span_handler_ctocpp.cc:147
    frame #4: 0x00f2fe80 libcef.dylib`CefBrowserHostImpl::DestroyBrowser(this=0x061df200) + 240 at browser_host_impl.cc:1201
    frame #5: 0x00f32acf libcef.dylib`CefBrowserHostImpl::CloseContents(this=0x061df200, source=0x06191c00) + 271 at browser_host_impl.cc:1611
    frame #6: 0x00f2c18a libcef.dylib`CefBrowserHostImpl::CloseBrowser(this=<unavailable>, force_close=<unavailable>) + 378 at browser_host_impl.cc:539
    frame #7: 0x00ee10f3 libcef.dylib`browser_host_close_browser(self=<unavailable>, force_close=0) + 179 at browser_host_cpptoc.cc:136
    frame #8: 0x0056f027 Centerstage`CefBrowserHostCToCpp::CloseBrowser(this=0x07c6ab80, force_close=false) + 135 at browser_host_ctocpp.cc:96
    frame #9: 0x0005c2fb Centerstage`cstage::WebEngine::shouldQuit(this=0x07a51800) + 1739 at WebEngine.cpp:178


Second call:

Code: Select all
* thread #1: tid = 0x35fdd2, 0x00034c42 Centerstage`cstage::CefClientImpl::OnBeforeClose(this=0x07a51310, browser=0xbfffb3a0) + 1666 at CefClientImpl.cpp:80, name = 'CrBrowserMain, queue = 'com.apple.main-thread, stop reason = breakpoint 1.1
    frame #0: 0x00034c42 Centerstage`cstage::CefClientImpl::OnBeforeClose(this=0x07a51310, browser=0xbfffb3a0) + 1666 at CefClientImpl.cpp:80
    frame #1: 0x00034d39 Centerstage`_ZThn20_N6cstage13CefClientImpl13OnBeforeCloseE9CefRefPtrI10CefBrowserE(this=0x07a51324, browser=<unavailable>) + 57 at CefClientImpl.cpp:83
    frame #2: 0x005a1732 Centerstage`life_span_handler_on_before_close(self=0x07a963e8, browser=0x07a86f88) + 338 at life_span_handler_cpptoc.cc:191
    frame #3: 0x00f0008f libcef.dylib`CefLifeSpanHandlerCToCpp::OnBeforeClose(this=<unavailable>, browser=<unavailable>) + 239 at life_span_handler_ctocpp.cc:147
    frame #4: 0x00f2fe80 libcef.dylib`CefBrowserHostImpl::DestroyBrowser(this=0x061df200) + 240 at browser_host_impl.cc:1201
    frame #5: 0x00f49058 libcef.dylib`CefContentBrowserClient::DestroyAllBrowsers(this=<unavailable>) + 344 at content_browser_client.cc:363
    frame #6: 0x00f4e279 libcef.dylib`CefContext::FinishShutdownOnUIThread(this=0x07a54390, uithread_shutdown_event=0xbfffb7c8) + 201 at context.cc:363
    frame #7: 0x00f4d9a7 libcef.dylib`CefContext::Shutdown(this=0x07a54390) + 519 at context.cc:308
    frame #8: 0x00f4cc4d libcef.dylib`(anonymous namespace)::CefForceShutdown::~CefForceShutdown() [inlined] (anonymous namespace)::CefForceShutdown::~CefForceShutdown() + 26 at context.cc:51
    frame #9: 0x00f4cc33 libcef.dylib`(anonymous namespace)::CefForceShutdown::~CefForceShutdown(this=0x048216d8) + 3 at context.cc:49
    frame #10: 0x97468faf libsystem_c.dylib`__cxa_finalize + 183
    frame #11: 0x974692da libsystem_c.dylib`exit + 31
    frame #12: 0x96a4c34b AppKit`-[NSApplication terminate:] + 2806
    frame #13: 0x0008cc74 Centerstage`-[AppImplCocoaBasic quit](self=0x07c34420, _cmd=0x00642c54) + 100 at AppImplCocoaBasic.mm:337
    frame #14: 0x000a480d Centerstage`cinder::app::AppBasic::quit(this=0x07a395f0) + 45 at AppBasic.cpp:273
    frame #15: 0x0005c3ea Centerstage`cstage::WebEngine::shutdown(this=0x07a51800) + 58 at WebEngine.cpp:194
    frame #16: 0x00034c66 Centerstage`cstage::CefClientImpl::OnBeforeClose(this=0x07a51310, browser=0xbfffbe20) + 1702 at CefClientImpl.cpp:81
    frame #17: 0x00034d39 Centerstage`_ZThn20_N6cstage13CefClientImpl13OnBeforeCloseE9CefRefPtrI10CefBrowserE(this=0x07a51324, browser=<unavailable>) + 57 at CefClientImpl.cpp:83
    frame #18: 0x005a1732 Centerstage`life_span_handler_on_before_close(self=0x07c39f38, browser=0x07c48d58) + 338 at life_span_handler_cpptoc.cc:191
    frame #19: 0x00f0008f libcef.dylib`CefLifeSpanHandlerCToCpp::OnBeforeClose(this=<unavailable>, browser=<unavailable>) + 239 at life_span_handler_ctocpp.cc:147
    frame #20: 0x00f2fe80 libcef.dylib`CefBrowserHostImpl::DestroyBrowser(this=0x061df200) + 240 at browser_host_impl.cc:1201
    frame #21: 0x00f32acf libcef.dylib`CefBrowserHostImpl::CloseContents(this=0x061df200, source=0x06191c00) + 271 at browser_host_impl.cc:1611
    frame #22: 0x00f2c18a libcef.dylib`CefBrowserHostImpl::CloseBrowser(this=<unavailable>, force_close=<unavailable>) + 378 at browser_host_impl.cc:539
    frame #23: 0x00ee10f3 libcef.dylib`browser_host_close_browser(self=<unavailable>, force_close=0) + 179 at browser_host_cpptoc.cc:136
    frame #24: 0x0056f027 Centerstage`CefBrowserHostCToCpp::CloseBrowser(this=0x07c6ab80, force_close=false) + 135 at browser_host_ctocpp.cc:96
    frame #25: 0x0005c2fb Centerstage`cstage::WebEngine::shouldQuit(this=0x07a51800) + 1739 at WebEngine.cpp:178


The second call actually stems back to the first, because I detected that all browsers had been closed (by me) and I issue a CefShutdown() call, which in turns is where I get another OnBeforeClose() with a reference to a different CefBrowser (as in, the CefBrowser's from each call have a different address).

Thanks for letting me know ParentWindowWillClose() is obsolete, I wasn't sure about when it needed to be called anyway (like, per browser? once at shutdown?) But glad that it is one less thing to worry about now.

cheers,
Rich
richeakin
Techie
 
Posts: 21
Joined: Mon Dec 16, 2013 11:50 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby magreenblatt » Tue Feb 04, 2014 5:07 pm

richeakin wrote:The second call actually stems back to the first, because I detected that all browsers had been closed (by me) and I issue a CefShutdown() call, which in turns is where I get another OnBeforeClose() with a reference to a different CefBrowser (as in, the CefBrowser's from each call have a different address).

You should not call CefShutdown in response to OnBeforeClose. Instead, CefShutdown should be called after the message loop has terminated and before the application exits (for example, at the end of your main() function). If you're using CefRunMessageLoop you should call CefQuitMessageLoop from OnBeforeClose to exit the message loop.
magreenblatt
Site Admin
 
Posts: 7982
Joined: Fri May 29, 2009 6:57 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby richeakin » Tue Feb 18, 2014 7:12 pm

magreenblatt wrote:You should not call CefShutdown in response to OnBeforeClose. Instead, CefShutdown should be called after the message loop has terminated and before the application exits (for example, at the end of your main() function). If you're using CefRunMessageLoop you should call CefQuitMessageLoop from OnBeforeClose to exit the message loop.


I'm afraid that I cannot get that far before a crash deep inside NSAutoreleasePool internals. If I instead just try to quit the app, planning to issue the CefShutdown later, the following crash occurs:

Code: Select all
* thread #1: tid = 0x273abb, 0x9a7d645a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 466, name = 'CrBrowserMain, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=2, address=0x10)
    frame #0: 0x9a7d645a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 466
    frame #1: 0x95495cdf CoreFoundation`_CFAutoreleasePoolPop + 47
    frame #2: 0x93f40934 Foundation`-[NSAutoreleasePool drain] + 122
    frame #3: 0x010b74b3 libcef.dylib`base::mac::ScopedNSAutoreleasePool::~ScopedNSAutoreleasePool() [inlined] base::mac::ScopedNSAutoreleasePool::~ScopedNSAutoreleasePool(this=<unavailable>) + 35 at scoped_nsautorelease_pool.mm:20
    frame #4: 0x010b749f libcef.dylib`base::mac::ScopedNSAutoreleasePool::~ScopedNSAutoreleasePool(this=0x0767e820) + 15 at scoped_nsautorelease_pool.mm:19
    frame #5: 0x035112ea libcef.dylib`content::ContentMainRunnerImpl::Shutdown() [inlined] base::DefaultDeleter<base::mac::ScopedNSAutoreleasePool>::operator(ptr=0x0767e820)(base::mac::ScopedNSAutoreleasePool*) const + 8 at scoped_ptr.h:137
    frame #6: 0x035112e2 libcef.dylib`content::ContentMainRunnerImpl::Shutdown() [inlined] base::internal::scoped_ptr_impl<base::mac::ScopedNSAutoreleasePool, base::DefaultDeleter<base::mac::ScopedNSAutoreleasePool> >::reset(base::mac::ScopedNSAutoreleasePool*) + 14 at scoped_ptr.h:246
    frame #7: 0x035112d4 libcef.dylib`content::ContentMainRunnerImpl::Shutdown() [inlined] scoped_ptr<base::mac::ScopedNSAutoreleasePool, base::DefaultDeleter<base::mac::ScopedNSAutoreleasePool> >::reset(base::mac::ScopedNSAutoreleasePool*) at scoped_ptr.h:367
    frame #8: 0x035112d4 libcef.dylib`content::ContentMainRunnerImpl::Shutdown(this=0x07678d60) + 388 at content_main_runner.cc:804
    frame #9: 0x00fc99d9 libcef.dylib`CefContext::Shutdown() [inlined] CefContext::FinalizeShutdown(this=0x07678ba0) + 50 at context.cc:384
    frame #10: 0x00fc99a7 libcef.dylib`CefContext::Shutdown(this=0x07678ba0) + 519 at context.cc:310
    frame #11: 0x00fc8c4d libcef.dylib`(anonymous namespace)::CefForceShutdown::~CefForceShutdown() [inlined] (anonymous namespace)::CefForceShutdown::~CefForceShutdown() + 26 at context.cc:51
    frame #12: 0x00fc8c33 libcef.dylib`(anonymous namespace)::CefForceShutdown::~CefForceShutdown(this=0x0489d6d8) + 3 at context.cc:49
    frame #13: 0x97468faf libsystem_c.dylib`__cxa_finalize + 183
    frame #14: 0x974692da libsystem_c.dylib`exit + 31
    frame #15: 0x96a4c34b AppKit`-[NSApplication terminate:] + 2806
    frame #16: 0x000a7924 Centerstage`-[AppImplCocoaBasic quit](self=0x072b27c0, _cmd=0x00687e10) + 100 at AppImplCocoaBasic.mm:337
    frame #17: 0x000bf4bd Centerstage`cinder::app::AppBasic::quit(this=0x070a4610) + 45 at AppBasic.cpp:273
    frame #18: 0x0006bf6c Centerstage`cstage::WebEngine::shutdown(this=0x07678b00) + 988 at WebEngine.cpp:198
    frame #19: 0x000365d6 Centerstage`cstage::CefClientImpl::OnBeforeClose(this=0x07678920, browser=0xbfffbb80) + 1702 at CefClientImpl.cpp:80
    frame #20: 0x000366a9 Centerstage`_ZThn20_N6cstage13CefClientImpl13OnBeforeCloseE9CefRefPtrI10CefBrowserE(this=0x07678934, browser=<unavailable>) + 57 at CefClientImpl.cpp:82
    frame #21: 0x005e36c2 Centerstage`life_span_handler_on_before_close(self=0x07080728, browser=0x07086308) + 338 at life_span_handler_cpptoc.cc:191
    frame #22: 0x00f7c08f libcef.dylib`CefLifeSpanHandlerCToCpp::OnBeforeClose(this=<unavailable>, browser=<unavailable>) + 239 at life_span_handler_ctocpp.cc:147
    frame #23: 0x00fabe80 libcef.dylib`CefBrowserHostImpl::DestroyBrowser(this=0x06a90400) + 240 at browser_host_impl.cc:1201
    frame #24: 0x00faeacf libcef.dylib`CefBrowserHostImpl::CloseContents(this=0x06a90400, source=0x06a8c200) + 271 at browser_host_impl.cc:1611
    frame #25: 0x00fa818a libcef.dylib`CefBrowserHostImpl::CloseBrowser(this=<unavailable>, force_close=<unavailable>) + 378 at browser_host_impl.cc:539
    frame #26: 0x00f5d0f3 libcef.dylib`browser_host_close_browser(self=<unavailable>, force_close=0) + 179 at browser_host_cpptoc.cc:136
    frame #27: 0x005b0fb7 Centerstage`CefBrowserHostCToCpp::CloseBrowser(this=0x070867f0, force_close=false) + 135 at browser_host_ctocpp.cc:96
    frame #28: 0x0006bace Centerstage`cstage::WebEngine::shouldQuit(this=0x07678b00) + 2350 at WebEngine.cpp:180
    ....


If I don't issue a manual shutdown ( essentially a [NSApp terminate:nil] on mac), then my main window closes but the application hangs.

There is an odd note above CefLifeSpanHandler::DoClose which I don't understand:

// 7. CEF sends an OS close notification.


So CEF tries to shut down the application at a system level? I don't believe this is happening, but even if it is, this would make it very awkward to use CEF in conjunction with any other framework (such as ours, cinder) which already tries to handle this. Likewise, having to override the main() function is in the similar boat; ideally a user should not have to modify their main function in order to add a WebView to their application.

Anywho, do you have any idea what the autorelease pool is choking on? This is seeming to be a problem for more than just myself amongst people trying to see if CEF is a viable option for intergrating web content into an existing graphics framework.

cheers,
Rich
richeakin
Techie
 
Posts: 21
Joined: Mon Dec 16, 2013 11:50 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby magreenblatt » Tue Feb 18, 2014 7:57 pm

richeakin wrote:Anywho, do you have any idea what the autorelease pool is choking on?

You're unloading libcef.dylib before CefShutdown is called, which causes CefShutdown to be executed by destruction of the CefForceShutdown global object -- don't do that. Are you using CefRunMessageLoop? If so, your CefClientImpl::OnBeforeClose should call CefQuitMessageLoop which will cause the CefRunMessageLoop function to return. You should then call CefShutdown.
magreenblatt
Site Admin
 
Posts: 7982
Joined: Fri May 29, 2009 6:57 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby richeakin » Tue Feb 18, 2014 8:08 pm

Thanks again Marshall for your support,

magreenblatt wrote:You're unloading libcef.dylib before CefShutdown is called, which causes CefShutdown to be executed by destruction of the CefForceShutdown global object -- don't do that.


If this is the case, I'm not sure how it is avoidable. The dylib is being unloaded by NSApp terminating, and if I don't do this, the app will not close.

magreenblatt wrote:Are you using CefRunMessageLoop? If so, your CefClientImpl::OnBeforeClose should call CefQuitMessageLoop which will cause the CefRunMessageLoop function to return. You should then call CefShutdown.


Not using CefRunMessageLoop() and can't because our framework needs to run its own message loop. So I am calling CefDoMessageLoopWork() once per update cycle. Hence, CefQuitMessageLoop() is not an option.

Is there something being cleaned up by CefQuitMessageLoop() that I could do as a manual step, before executing CefShutdown()? Waiting is not a problem, the issue is allowing our framework to control the app lifecycle, while still properly cleaning up chromium before shutdown.
richeakin
Techie
 
Posts: 21
Joined: Mon Dec 16, 2013 11:50 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby magreenblatt » Tue Feb 18, 2014 11:28 pm

In that case you need to (1) wait for the call stack to unwind from OnBeforeClose, (2) call CefShutdown and (3) terminate the application. Don't terminate the application directly from the OnBeforeClose callback.
magreenblatt
Site Admin
 
Posts: 7982
Joined: Fri May 29, 2009 6:57 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby richeakin » Wed Feb 19, 2014 4:50 pm

Hm, that seemed promising but unfortunately I'm still getting an EXC_BAD_ACCESS from the ScopedNSAutoReleasePool destructor. So, the new course of action is:

  • receive system shutdown message
  • close all browsers
  • when browser count is zero, set a boolean that the app is OK to shutdown
  • in app update, see the boolean is flagged and wait and skip 60 frames for good measure.
  • after the skipped frames, call CefShutdown()

At this point, I get a crash with the following stacktrace:

Code: Select all
* thread #1: tid = 0x32616e, 0x9a7d645a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 466, name = 'CrBrowserMain, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=2, address=0x10)
    frame #0: 0x9a7d645a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 466
    frame #1: 0x95495cdf CoreFoundation`_CFAutoreleasePoolPop + 47
    frame #2: 0x93f40934 Foundation`-[NSAutoreleasePool drain] + 122
    frame #3: 0x010b74b3 libcef.dylib`base::mac::ScopedNSAutoreleasePool::~ScopedNSAutoreleasePool() [inlined] base::mac::ScopedNSAutoreleasePool::~ScopedNSAutoreleasePool(this=<unavailable>) + 35 at scoped_nsautorelease_pool.mm:20
    frame #4: 0x010b749f libcef.dylib`base::mac::ScopedNSAutoreleasePool::~ScopedNSAutoreleasePool(this=0x06e6c180) + 15 at scoped_nsautorelease_pool.mm:19
    frame #5: 0x035112ea libcef.dylib`content::ContentMainRunnerImpl::Shutdown() [inlined] base::DefaultDeleter<base::mac::ScopedNSAutoreleasePool>::operator(ptr=0x06e6c180)(base::mac::ScopedNSAutoreleasePool*) const + 8 at scoped_ptr.h:137
    frame #6: 0x035112e2 libcef.dylib`content::ContentMainRunnerImpl::Shutdown() [inlined] base::internal::scoped_ptr_impl<base::mac::ScopedNSAutoreleasePool, base::DefaultDeleter<base::mac::ScopedNSAutoreleasePool> >::reset(base::mac::ScopedNSAutoreleasePool*) + 14 at scoped_ptr.h:246
    frame #7: 0x035112d4 libcef.dylib`content::ContentMainRunnerImpl::Shutdown() [inlined] scoped_ptr<base::mac::ScopedNSAutoreleasePool, base::DefaultDeleter<base::mac::ScopedNSAutoreleasePool> >::reset(base::mac::ScopedNSAutoreleasePool*) at scoped_ptr.h:367
    frame #8: 0x035112d4 libcef.dylib`content::ContentMainRunnerImpl::Shutdown(this=0x06e6c040) + 388 at content_main_runner.cc:804
    frame #9: 0x00fc99d9 libcef.dylib`CefContext::Shutdown() [inlined] CefContext::FinalizeShutdown(this=0x06e6ca60) + 50 at context.cc:384
    frame #10: 0x00fc99a7 libcef.dylib`CefContext::Shutdown(this=0x06e6ca60) + 519 at context.cc:310
    frame #11: 0x00fc96df libcef.dylib`CefShutdown() + 207 at context.cc:130
    frame #12: 0x005a3784 Centerstage`CefShutdown() + 36 at libcef_dll_wrapper.cc:164
    frame #13: 0x0006c0dd Centerstage`cstage::WebEngine::shutdown(this=0x06e8fd60) + 525 at WebEngine.cpp:190
    frame #14: 0x0006b448 Centerstage`cstage::WebEngine::update(this=0x06e8fd60) + 648 at WebEngine.cpp:201


If I skip the CefShutdown() and just terminate my application (with the intent of calling CefShutdown() at the end of main), I get an almost identical stacktrace.

Still something residual?

Another hint is that I'm getting the following message in the console at the time of the EXC_BAS_ACCESS:

Code: Select all
CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.


Enabling CA_DEBUG_TRANSACTIONS=1, however, didn't provide any more information.
richeakin
Techie
 
Posts: 21
Joined: Mon Dec 16, 2013 11:50 pm

Re: Still Debugging shutdown crash, ghost CefBrowser

Postby bugra » Mon Dec 29, 2014 4:33 pm

I've been struggling trying to integrate CEF into an existing Cocoa app using CefDoMessageLoopWork and I ran into the same AutoreleasePoolPage::pop crash during shutdown. After looking at Chromium's code a bit, I think the issue is that, when my app's autorelease pool pops off the stack (at the end of a message loop), it takes with it the one that Chromium created (since it gets created later when initializing CEF). So when CefShutdown is called, Chromium tries to release its autorelease pool, which has already been popped off the stack. Hence the crash.

I worked around the issue by moving CEF initialization way upstream into the app's main function, before the NSApplicationMain call. This is horrible for modularity but I can't see any other way. Not much CEF can do about this either, Chromium just seems to assume it owns the main process.

Hope that helps someone.
bugra
Newbie
 
Posts: 1
Joined: Mon Dec 29, 2014 4:15 pm


Return to Support Forum

Who is online

Users browsing this forum: Bing [Bot] and 14 guests