Should I clean up pending URL requests on shutdown?

[grossag]

I am running into crashes on shutdown if I have a pending CefURLRequest (created using CefURLRequest::Create) in CefBrowserMainParts::PostDestroyThreads because of the following code:

Code: Select all

#ifndef NDEBUG
  // No CefURLRequestContext instances should exist at this point.
  DCHECK_EQ(0, CefURLRequestContext::DebugObjCt);
#endif


Previously I was not maintaining any references of my own to the pending CefURLRequest and CefURLRequestClient objects, just figuring that Cef would clean them up when done. But it appears that Cef is expecting me to cancel them if they are still pending; is that right? If so, how would I even do that? I tried keeping a list of pending CefURLRequestClient objects then canceling the associated CefURLRequest on shutdown, but I ran into thread-safety assertions in CefBrowserURLRequest::Cancel because I was calling it from my UI thread.

[magreenblatt]

Yes, you should cancel them. Keep a list of pending requests. Presumably you're calling CefShutdown() from somewhere currently. Before calling CefShutdown() post a task to the IO thread that cancels the requests, then post a task back to the UI thread that calls CefShutdown().

[grossag]

Ok, thanks, I hadn't found cef_task.h until now; that should work.

[grossag]

Edit: nevermind, I found that "include/internal/cef_types.h" (for the thread ID enums) comes by including "include/cef_base.h".

Follow-up question for you. Is it safe to include files under "include/internal" in a client application? Or are their filenames subject to change? I found that only "include/cef_base_capi.h" includes "include/internal/cef_types.h" so I'm not sure which one to use.

[magreenblatt]

Including "include/internal/cef_types.h" should be safe.

[grossag]

I'm still having troubles on shutdown, particularly if a web page is loading when I shut down. This is even if I don't send any URL requests. At that point I hit DCHECK_EQ(0, CefBrowserContext::DebugObjCt). I have released my reference to my CefBrowser object but it appears that Cef still has its own reference because the request is active.

So I guess I have the following questions:

1. What should I do to avoid this crash? I would try and cancel the CefBrowser request but AFAICT CefBrowser::StopLoad can only be called from the render process. And after this, is there a required wait period for Cef to release its internal references to CefBrowser so it will be destroyed?
2. Is it expected that calling CefURLRequest::Cancel will synchronously release all internal references to that CefURLRequest?

Edit: as a note, I'm on Windows and am using multi_threaded_message_loop=1. I shut down based on a Windows message WM_CLOSE in my main application window, which is on my application's UI thread and not in response to any Chromium notifications; this is the same thread as I originally called CefInitialize on. My shutdown order when I have no active CefURLRequest objects is to release my CefRefPtr<CefBrowser> reference using "mBrowser = NULL;" then immediately call CefShutdown().

[magreenblatt]

Are you able to reproduce the CefBrowserContext DCHECK problem in cefclient?

Is it expected that calling CefURLRequest::Cancel will synchronously release all internal references to that CefURLRequest?

It's not synchronous, but calling Cancel will trigger all of the necessary behaviors (posted tasks, etc). If you then call CefShutdown asynchronously you should be OK.

[RenderMonkey]

We have been hitting this (or similiar issue) on Linux (2623) a lot lately and I am guessing it is related.
It is reproducible in cefsimple

Code: Select all

antonb@antonb-comp:~/code/cef_2623/chromium/src/cef$ ./../out/Debug/cefsimple --url=www.fz.se
[0425/150057:WARNING:cefsimple_linux.cc(14)] X error received: type 0, serial 307, error_code 8, request_code 42, minor_code 0

[0425/150059:WARNING:x11_util.cc(1407)] X error received: serial 160, error_code 181 (GLXBadWindow), request_code 154, minor_code 32 (Unknown)
[0425/150059:WARNING:x11_util.cc(1407)] X error received: serial 163, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[0425/150059:FATAL:browser_main.cc(189)] Check failed: 0 == CefBrowserContext::DebugObjCt (0 vs. 1)
#0 0x7f7668d99cae base::debug::StackTrace::StackTrace()
#1 0x7f7668de5e3f logging::LogMessage::~LogMessage()
#2 0x7f7668a84e4a CefBrowserMainParts::PostMainMessageLoopRun()
#3 0x7f766fbeff79 content::BrowserMainLoop::ShutdownThreadsAndCleanUp()
#4 0x7f766fbf5fbb content::BrowserMainRunnerImpl::Shutdown()
#5 0x7f7668bcfe9e CefMainDelegate::ShutdownBrowser()
#6 0x7f7668aa246d CefContext::FinalizeShutdown()
#7 0x7f7668aa19a9 CefContext::Shutdown()
#8 0x7f7668aa16d1 CefShutdown()
#9 0x7f76689666ad cef_shutdown
#10 0x00000041013d CefShutdown()
#11 0x00000040d4cf main
#12 0x7f7666dc1a40 __libc_start_main
#13 0x000000405f49 _start

Aborted (core dumped)


Happens fairly often in cefsimple when loading the page, just start cefsimple and close it down when it loads the site.

Edit:
Happens in cefclient as well.