CefRequestContext leaks

Having problems with building or using CEF's C/C++ APIs? This forum is here to help. Please do not post bug reports or feature requests here.

CefRequestContext leaks

Postby lavv17 » Tue Sep 11, 2018 4:22 am

Hello!

I have a problem with memory leak, if I create CefRequestContext like this:
Code: Select all
context = CefRequestContext::CreateContext( CefRequestContext::GetGlobalContext(), handler );

I use the context for creating a browser. The problem is that the handler is never released until CefShutdown(), even when the browser is destroyed (OnBeforeClose is called normally).
lavv17
Techie
 
Posts: 23
Joined: Tue May 22, 2018 8:50 am

Re: CefRequestContext leaks

Postby ndesktop » Tue Sep 11, 2018 5:30 am

I'm using a sequence like:
(initialization)
Code: Select all
CefRefPtr<CefRequestContext> m_SharedRequestContext; // declaration

// browser creation: m_Handler is my implementation of client handler class, called ClientHandler
void MainWindow::CreateBrowser()
{
...
   return CefBrowserHost::CreateBrowser(
        info,
        static_cast<CefRefPtr<CefClient>>(m_Handler),
        url,
        settings,
        GetRequestContext(m_Handler.get()) // <== GetRequestContext
    );
}

CefRefPtr<CefRequestContext> MainWindow::GetRequestContext(ClientHandler* client_handler)
{
    DCHECK(CefCurrentlyOn(TID_UI));
    return client_handler->GetRequestContext(client_handler);
}

...

CefRefPtr<CefRequestContext> ClientHandler::GetRequestContext(ClientHandler* client_handler)
{
...
    if(m_SharedRequestContext.get() == nullptr)
    {
        m_SharedRequestContext =
            CefRequestContext::CreateContext(
                CefRequestContext::GetGlobalContext(),
                new ClientRequestContextHandler(this)
            );
    }
    DCHECK(m_SharedRequestContext.get());
    return m_SharedRequestContext;
}


Obviously, I am using a shared context among all browser.

The cleanup is done when a WM_CLOSE is posted to my main window class (my app is a single main window with multiple tabs)

It looks something like this:
Code: Select all
BOOL MainWindow::_DoClose()
{
...
        //  signal handler as closing
        m_ClientHandler->setClosing(true);
...
}

void ClientHandler::setClosing(bool v)
{
    ...
    m_SharedRequestContext = nullptr;
}


ClientHandler::setClosing place m_SharedRequestContext on nullptr and thus releasing the shared context.
ndesktop
Master
 
Posts: 756
Joined: Thu Dec 03, 2015 10:10 am

Re: CefRequestContext leaks

Postby lavv17 » Tue Sep 11, 2018 6:14 am

In my case I need a separate CefRequestContext for separate CefCookieManager for each window, thus I have to create a new helper each time and it does not get reseased :(
lavv17
Techie
 
Posts: 23
Joined: Tue May 22, 2018 8:50 am

Re: CefRequestContext leaks

Postby ndesktop » Tue Sep 11, 2018 6:28 am

Then perhaps store the contexts in a map[browserID]=CefRefPtr<context> and release them all in the same manner.
When a browser is released (ClientHandler::DoClose(CefRefPtr<CefBrowser> browser)) remove the context from the map.
ndesktop
Master
 
Posts: 756
Joined: Thu Dec 03, 2015 10:10 am

Re: CefRequestContext leaks

Postby lavv17 » Tue Sep 11, 2018 6:41 am

I don't hold any reference to the context at all, and yet it is not released along with the browser.
lavv17
Techie
 
Posts: 23
Joined: Tue May 22, 2018 8:50 am

Re: CefRequestContext leaks

Postby lavv17 » Tue Sep 11, 2018 8:04 am

Here is the place in code which prevents the handler release:
https://bitbucket.org/chromiumembedded/ ... mpl.cc-653
So it is released only when the global context is destroyed.
lavv17
Techie
 
Posts: 23
Joined: Tue May 22, 2018 8:50 am

Re: CefRequestContext leaks

Postby ndesktop » Wed Sep 12, 2018 5:31 am

Then maybe this is by design? Is there a DCHECK, DebugObjCt or whatever which appears on shutdown?
Does the cefclient shows the same issue?
ndesktop
Master
 
Posts: 756
Joined: Thu Dec 03, 2015 10:10 am

Re: CefRequestContext leaks

Postby Czarek » Wed Sep 12, 2018 6:11 am

Related issue? https://bitbucket.org/chromiumembedded/ ... rom-global

The solution is to keep the object until browser is destroyed and call object.Release() manually. This way you can force to release reference acquired by other code. Check that there is only one reference count by calling object.HasOneRef() to make sure that the object will be destroyed.
Maintainer of the CEF Python, PHP Desktop and CEF C API projects. My LinkedIn.
User avatar
Czarek
Virtuoso
 
Posts: 1927
Joined: Sun Nov 06, 2011 2:12 am

Re: CefRequestContext leaks

Postby lavv17 » Wed Sep 12, 2018 7:36 am

Won't it crash after Release() if there is a reference left somewhere in the global context?
lavv17
Techie
 
Posts: 23
Joined: Tue May 22, 2018 8:50 am

Re: CefRequestContext leaks

Postby Czarek » Wed Sep 12, 2018 7:42 am

The CEF code usually checks if reference pointers hold actual objects by calling refptr.get(), but you won't know until you test it.
Last edited by Czarek on Thu Sep 13, 2018 12:58 am, edited 1 time in total.
Maintainer of the CEF Python, PHP Desktop and CEF C API projects. My LinkedIn.
User avatar
Czarek
Virtuoso
 
Posts: 1927
Joined: Sun Nov 06, 2011 2:12 am

Next

Return to Support Forum

Who is online

Users browsing this forum: No registered users and 59 guests