Exception on startup in CEF 3497.1829

[ndesktop]

It depends on so many things. Incompatibility between compilers is something I saw from time to time, runtimes, even compiler bugs etc.
But on the other hand at work (major AV company) we integrate antispam built with VS 2013, AV modules with 2012/13/15/17, libcef 2017 (in fact, I triggered migration to 2017 it because libcef stopped supporting 2015) etc.

I can't say for sure what is your situation, but, if possible, try to build with the same compiler.
If you cannot (not building CEF yourself, using it via CefSharp etc.) then it should be a compatibility issue.
Finally, look for PATH quirks (runtimes/dlls load from another directory). Open a console, set path to system32 only, then launch your exe directly.
Dependency walker might also help.

[callum]

I've updated the version of CEF I build my app against dozens of times over the last few years and apart from minor interface changes, it's been painless in the past so I don't think it's anything like path changes or 32/64bit mismatches.

I did notice that a standalone app simple app I made when build against the latest Win 64 CEF does work correctly so that gives me somewhere to start looking and probably discounts the VS 2013/2015/2017 theory.

Best guess before I look is a setting in the main app which isn't present in the simple version is causing issues.

Simple test app is here: https://github.com/callumprentice/cef_opengl_win

[callum]

The simple app works as expected until I transplant some cookie initialization code from the main app that executes just before CefBrowserHost::CreateBrowserSync(..) is called like this:

Code: Select all

CefRefPtr<CefCookieManager> manager = CefCookieManager::GetGlobalManager(nullptr);
if (manager)
{
   bool persist_session_coookies = false;
   std::string cookie_path = ".\\cookies";
   manager->SetStoragePath(cookie_path, persist_session_coookies, nullptr);
}


then I see the same exception. That code has been in there for years without causing an issue.

Without being able to see symbols in the stack trace, I've no idea if it's the same issue but it seems likely that it's related.

Surprisingly, when I do the reverse and remove the cookie manager code from the main app, it doesn't hit the exception but doesn't render anything so there may be more going on.

[ndesktop]

Use OutputDebugString then and try/catch, at least to poinpoint the exception line and code.
My best bet would be
1. sqlite exception
2. readonly path.

SetStoragePath ends up calling CefURLRequestContextGetterImpl::SetCookieStoragePath.
There are quite a few things that might bomb if path is not considered ok.

Try with an absolute path to see if is still bombing.

[salvadordf]

The simple app works as expected until I transplant some cookie initialization code from the main app that executes just before CefBrowserHost::CreateBrowserSync(..) is called like this:

Code: Select all

CefRefPtr<CefCookieManager> manager = CefCookieManager::GetGlobalManager(nullptr);
if (manager)
{
   bool persist_session_coookies = false;
   std::string cookie_path = ".\\cookies";
   manager->SetStoragePath(cookie_path, persist_session_coookies, nullptr);
}


I had exactly the same problem. I also set the path for the cookies with the global cookie manager at startup and the app crashed.

The stack trace showed something about the cookie manager and I saw that cefclient always uses a callback to get it.

I added the callback to GetGlobalManager and the problem was solved.

[ndesktop]

Strange, the run async call checks if the callback is null, and if so, returns.
Check the 3497 source code:
- RunAsyncCompletionOnIOThread

Code: Select all

void RunAsyncCompletionOnIOThread(CefRefPtr<CefCompletionCallback> callback) {
  if (!callback.get())
    return;
  CEF_POST_TASK(CEF_IOT,
                base::Bind(&CefCompletionCallback::OnComplete, callback.get()));
}


- SetStoragePathWithContext also calls RunAsyncCompletionOnIOThread
- SetSupportedSchemesInternal calls SetSupportedSchemesWithContext -or- RunAsyncCompletionOnIOThread
- finally, SetSupportedSchemesWithContext again calls RunAsyncCompletionOnIOThread

I'm not saying there isn't something I missed. But I can't say why passing a non-null callback fixes the crash.

[callum]

Digesting these last few posts - thank you.

I didn't get a notification about new posts despite that checkbox being set - I'm glad I decided to check manually just now.

[callum]

Adding a callback to GetGlobalManager(..) that does nothing except wait for completion didn't change anything. Is that what the callback you mentioned did too?

Oddly enough, removing the lines that trigger the exception ( manager->SetStoragePath(cookie_path, persist_session_coookies, nullptr);) lets the app run correctly but it will never exit. The usual "app requests exit" -> CloseBrowser() -> OnBeforeClose() -> PostQuitMessage(0) chain happens as expected but my message loop never exits - presumably because something else inside CEF eats the WM_QUIT message.

[salvadordf]

Yes. That's the callback I was referring to.
Unfortunately, there seems to be additional issues in that app.

I tested my app again with the old cookie path initialization without a callback.

When I call "cef_cookie_manager_get_global_manager" inside CefBrowserProcessHandler.OnContextInitialized without a callback and try to set a new path for the cookies I get a crash with this trace :

Code: Select all

ntoskrnl.exe!KiSwapContext+0x26
ntoskrnl.exe!KiSwapThread+0x266
ntoskrnl.exe!KiCommitThreadWait+0x1df
ntoskrnl.exe!KeWaitForSingleObject+0x393
ntoskrnl.exe!DbgkpQueueMessage+0x279
ntoskrnl.exe!DbgkpSendApiMessage+0x44
ntoskrnl.exe!DbgkForwardException+0xeb
ntoskrnl.exe!KiDispatchException+0x24a
ntoskrnl.exe!CommonDispatchException+0x4a
ntoskrnl.exe!Kei386EoiHelper+0x1de
libcef.dll!network::CookieManager::AddGlobalChangeListener+0x60
libcef.dll!network::mojom::CookieManagerProxy_AddGlobalChangeListener_Message::Dispatch+0x2b
libcef.dll!network::mojom::CookieManagerStubDispatch::Accept+0x623
libcef.dll!network::mojom::CookieManagerStub<mojo::RawPtrImplRefTraits<network::mojom::CookieManager> >::Accept+0x13
libcef.dll!mojo::internal::MultiplexRouter::ProcessIncomingMessage+0x17d
libcef.dll!mojo::internal::MultiplexRouter::Accept+0xae
libcef.dll!mojo::Connector::ReadSingleMessage+0xf1
libcef.dll!mojo::Connector::ReadAllAvailableMessages+0x48
libcef.dll!mojo::Connector::OnHandleReadyInternal+0x23
libcef.dll!base::internal::Invoker<base::internal::BindState<void (network::mojom::CookieManager_DeleteCookies_ProxyToResponder::*)(unsigned int) __attribute__((thiscall)),std::unique_ptr<network::mojom::CookieManager_DeleteCookies_ProxyToResponder,std::d
libcef.dll!mojo::SimpleWatcher::DiscardReadyState+0xf
libcef.dll!base::internal::Invoker<base::internal::BindState<void (*)(const base::RepeatingCallback<void (unsigned int)> &, unsigned int, const mojo::HandleSignalsState &),base::RepeatingCallback<void (unsigned int)> >,void (unsigned int, const mojo::Hand
libcef.dll!mojo::SimpleWatcher::OnHandleReady+0x89
libcef.dll!base::internal::Invoker<base::internal::BindState<void (mojo::SimpleWatcher::*)(int, unsigned int, const mojo::HandleSignalsState &) __attribute__((thiscall)),base::WeakPtr<mojo::SimpleWatcher>,int,unsigned int,mojo::HandleSignalsState>,void ()
libcef.dll!base::debug::TaskAnnotator::RunTask+0xe2
libcef.dll!base::MessageLoop::RunTask+0x1be
libcef.dll!base::MessageLoop::DeferOrRunPendingTask+0x53
libcef.dll!base::MessageLoop::DoWork+0xd3
libcef.dll!base::MessagePumpForIO::DoRunLoop+0x135
libcef.dll!base::MessagePumpWin::Run+0x41
libcef.dll!base::MessageLoop::Run+0x1f
libcef.dll!base::RunLoop::Run+0x2e
libcef.dll!base::Thread::Run+0xb
libcef.dll!content::BrowserProcessSubThread::IOThreadRun+0x24
libcef.dll!base::Thread::ThreadMain+0x14d
libcef.dll!base::`anonymous namespace'::ThreadFunc+0xbb
kernel32.dll!BaseThreadInitThunk+0xe
ntdll.dll!__RtlUserThreadStart+0x70
ntdll.dll!_RtlUserThreadStart+0x1b


Please, post your trace when you fix your Visual Studio issues. Perhaps we are experiencing a different issue.

I forgot to tell that I fixed this by moving the cookie path initialization code to a different thread. Now I get the global cookie manager with a callback inside a custom thread while CEF continues initializing.

[salvadordf]

The code comments for cef_cookie_manager_get_global_manager are these :

Code: Select all

///
// Returns the global cookie manager. By default data will be stored at
// CefSettings.cache_path if specified or in memory otherwise. If |callback| is
// non-NULL it will be executed asnychronously on the IO thread after the
// manager's storage has been initialized. Using this function is equivalent to
// calling cef_request_tContext::cef_request_context_get_global_context()->get_d
// efault_cookie_manager().
///

Perhaps calling cef_cookie_manager_get_global_manager(null) before the manager's storage has been initialized causes the crash.