libCef 退出流程整理

1.Check failed: !IsCefShutdown(). Object reference incorrectly错误原因

在实际的开发中，我们在退出cef时候可能会遇到如上的提示错误信息。
我们先来从这个错误信息能得出那些重要的信息：

• 首先它只有在debug模式下才会出现的错误，因为release版关闭检测。
• 其次，我们可以简单的了解到对象被不正确的引用。再翻译下就是在退出的时候，资源没有正确的释放。

就是退出的时候资源没有清理，造成了资源泄露

2.解决方案：

既然知道了原因了。修起来也就不像无头苍蝇乱撞了。

void SimpleHandler::OnBeforeClose(CefRefPtr<CefBrowser> browser) {
    CEF_REQUIRE_UI_THREAD();

    // Remove from the list of existing browsers.
    BrowserList::iterator bit = browser_list_.begin();
    for (; bit != browser_list_.end(); ++bit) {
        if ((*bit)->IsSame(browser)) {
            browser_list_.erase(bit);
            break;
        }
    }

    if (browser_list_.empty())
    {
        // 增加一个退出flag，如果所有的browser都退出了，此flag为true
        is_can_quit_ = true;
    }
}

// 主窗口增加WaitCefQuit
void QtWidgetsApplication1::WaitCefQuit()
{
    while (!simple_handler_->IsCanQuit())
    {
        Sleep(500);
        // 处理其他事件，不至于堵塞
        qApp->processEvents();
    }
}

// 在main函数中
int main(int argc, char *argv[])
{
	...
    QApplication app(argc, argv);
    QtWidgetsApplication1 widget;
    widget.show();
    app.exec();
    // 等待所有的browser退出
    widget.WaitCefQuit();
    // 关闭CEF，释放资源
    CefShutdown(); 
    return 0;
}

以上是我的修复方案，如果对你没有任何的效果，那可能需要好好看看下面的原理介绍

3.browser close流程

要是在2年前，我遇到这样的错误。我肯定是摆摆手，管它呢，我着急上线发版本呢，况且只有debug模式下才能出现，对用户没有伤害。

但是现在我认为每次出现这种诡异的问题，都是一次非常难得的学习机会。

上面的bug每次都能够稳定复现，嘿嘿，也是比较幸运的。（偶现的bug才是最恶心人的）

以下就是我修复bug的心路历程，请大家注意体会

3.1 全网狂搜

最开始遇到的这个问题的时候，我知道肯定有人遇到了。立马google起来了，的的确确是有人遇到了。我在libCef的官方论坛看到了关键字，里面有人提到了的确就是资源泄露的原因，但是只字未提是哪个资源泄露，怎么泄露的。但是下面有人说：“嗯，的确是资源泄露了。我关闭browser就好了。”。看得我又高兴又着急，立马回复了一条：”brother, How to fix it? please show me demo code.“。3周过去了对方到现在没有回复我。

3.2 加上libcef.pdb文件调试

没办法只好自己家硬着头皮去看，看了几天下面的堆栈信息，束手无策

最后我想到了一个法子，我记得libcef有pdb文件可以看更详细的堆栈信息。立马下载了对应的pdb文件，解压放到libcef.dll同目录下。一个pdb文件就有3G大小，

机器的硬盘干的咔咔响。

再看堆栈信息：

嘿，别说，这下好看多了。至少对我来说不在是一个黑盒子了。看到了一些关键函数DestroyBrowser() ,OnBeforeClose()等等。

既然看到了堆栈信息，我就顺着这信息一个个点过去，瞅瞅呗。

哎……看了好几天发现这个堆栈信息还是不行啊。

得需要源码啊

3.3 libCef源码下载和探索

立马去了libCef官网去翻文档，文档上说了，libCef源码还需要先下载chromium源码。沃日，一顿操作猛如虎，一个星期过去了，各路源码都下载齐了。当然中间我可没有闲着，没事就去翻两眼代码。

源码怎么下载的就先不介绍了，但是有个巨坑大家要避免就是在下载的一定不要下载git的提交历史记录，这个记录拉下来就有36G之大，比源码还要大几倍。下载记得要去看命令行的帮助参数，有个参数是可以去掉历史记录的。

追源码是一件痛苦的事情，但也是提升自身实力的一种好方式。

源码下载好了，源码那么大啊几十G，从哪里开始呢。这是一件很讲究的事情，弄得不好，一无所获，顺便打击了自信。我深有体会，因为我常常是早上5,6点起来啥也不干就开始阅读代码，看了2个小时之后发现啥也没有捞着，头还疼。

看源码我有几点心得和大家讨论下：

• 从bug出发或者是说从特性去找，慢慢的往下找
• 带着目的去看，比如说我就想看看这个browser close是怎么样的。
• 只看框架，适当的跳过细节
• 要有心理预期，这玩意真的不简单。不是一两天就能看明白。

这没有说到调试模式去看代码，因为我没有实在不想编译了chromium，太费时间了。

看代码的工具我就用vs2019+vs code就可以了。

这次我们就从报出异常的地方看起。从堆栈信息一点点看过去。

我们来看①层函数代码:

这里面我省略了很多的代码

LRESULT CALLBACK CefBrowserPlatformDelegateNativeWin::WndProc(HWND hwnd,
                                                              UINT message,
                                                              WPARAM wParam,
                                                              LPARAM lParam) {
  ...
      
  switch (message) {
    case WM_CLOSE:
      if (browser && !browser->TryCloseBrowser()) {
        // Cancel the close.
        return 0;
      }

      // Allow the close.
      break;
    case WM_NCDESTROY:
      if (platform_delegate) {
        // Clear the user data pointer.
        gfx::SetWindowUserData(hwnd, NULL);
        static_cast<AlloyBrowserHostImpl*>(browser)->WindowDestroyed();
      }
      break;
    ...  
  }

  return DefWindowProc(hwnd, message, wParam, lParam);
}

试想一下，我们关闭窗口的时候，首先收到的一个消息WM_CLOSE消息。

1. 首先尝试去关闭CloseBrowser，并且拒绝系统继续往下执行

2. 在TryCloseBrowser->CloseBrowser()->CloseContents()->

   ​ std::unique_ptr::CloseHostWindow 这里最后又会POST WM_CLOSE到父窗口中

   ​ 注意CefBrowserPlatformDelegate是个父类，最后在不同的平台实例的class是不一样的。在windows平台中CefBrowserPlatformDelegateNativeWin

   browser_platform_delegate_create.cc文件中CreateNativeDelegate函数实例化

3. 最后接受到WM_CLOSE，窗口正常退出，先发送WM_DESTROY消息之后，再发送WM_NCDESTROY消息，就是上面的代码了。

4. CloseBrowser()->CloseContents()->DestroyBrowser()->OnBeforeClose()（这个就是我们的回调函数了，相当的熟悉啊）

我知道文字大家理解起来肯定很抽象。

所以我画了两张图：


这样大家根据这个框架看起来就简洁多了。

但是大家在看的时候一定要注意，整体的流程并不是一条线的。这个中间穿插了各种异步任务的，我是为了简单才这样的。

其实浏览器的关闭流程远远不止这么简单的，我只是分析了部分框架而已。

当时我看到这里的代码时候，我有几个疑问：

• 为什么第一次的时候不直接退出去呢？
• 我还是不理解它的关闭怎么影响我的代码。

我先来回答第一个问题：

第一次的时候不能直接退出去，是因为网页在退出的时候还有个javascript兄弟，它可能还在执行，因为它也会接受到退出事件的通知，弹出dialog，让用户确认是否退出。就是里面有个DoClose接口就是做个事情的。这块内容我没有看，因为我不懂前端这一套啊。

第二个问题还是需要回到我们自己的代码：

再从堆栈中找信息，从这里可以看到其实还没有执行我们的重载函数OnBeforeClose就assert了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SmWBCDEn-1641985757998)(.\browser_close_check_error\3_rounder.png)]

我们再去看这个assert代码：正如名字所说的那样，就是断言cef没有被shutdown。但实际情况是cef被shutdown了

void AssertNotShutdown() {
  DCHECK(!IsCefShutdown())
      << "Object reference incorrectly held at CefShutdown";
}

再去看IsCefShutdown里面有什么：其实就是个原子变量，调用SetCefShutdown就会设置为true

哦，到了这里我终于明白是什么错误了。就是我cef准备关闭，结果被人截胡了，有人先调用SetCefShutdown设置那个变量为true

std::atomic_bool g_cef_shutdown{false};

bool IsCefShutdown() {
  return g_cef_shutdown.load();
}

void SetCefShutdown() {
  g_cef_shutdown.store(true);
}

哎呀，不容易，分析到这里，我终于有一点点头绪了。立马全局搜索SetCefShutdown()，发现在shutdown_checker::SetIsShutdown()调用，再搜索。

最后在libcef_dll_wrapper.cc中CefShutdown()调用shutdown_checker::SetIsShutdown()

我们再整理下流程：

CefShutdown()

​ -> shutdown_checker::SetIsShutdown()

​ -> shutdown_checker::SetCefShutdown()

噢，我们发现源头就是CefShutdown()，而这个就是main()会调用。

好了，我终于明白了。原来就是Qt退出消息循环了，然后去执行CefShutdown()设置变量为ture。这时候再去销毁browser，导致先后顺序不一致。

这是Qt消息循环退出的太快了？

来，增加一行代码测试测试就知道了。我直接在CefShutdown()之前Sleep(10*1000)不就可以了？

看到这一行代码，我自己都夸自己如此的机智。

经过一番测试，果然如我所猜测的。

但是在生产环境不可能直接睡眠10s的，所以就有了，开头我给出的方案。

到这里我的分析就结束了，整个过程可谓是山穷水复疑无路，柳暗花明又一村，最后的收获却是满满的。

我希望大家不是直接拿我的解决方案，而是学习我分析的思路。我们不是为了解决一个问题，而是为了干掉所有相似模式的问题。这才是最重要的。

在这里还是要谢谢这位大佬的，他的文章给我了很大的启发：

https://github.com/fanfeilong/cefutil