关闭

breakpad进程外dump捕获浅析

标签: breakpad源码解析
423人阅读 评论(0) 收藏 举报

breakpad有两种dump捕获方式,进程内和进程外,很直观,进程内就是在进程内处理crash,而进程外是采用C/S结构,有一个独立的server端对crash进行处理,并生成dump。这里可以参照google-breakpad的官方demo,有一个crash_generation_app的例子,里面有具体的如何部署进程外,这个例子采用的UI的复用,它会去判断是否已经启动服务端,如果没有,则当前进程则作为服务端,如果存在服务端,则作为客户端,并可以在服务端上监控到客户端的连接,断开以及发生crash的情况。还有就是它这里的图形界面用的是windows.h下的windows api,如果想用QT,或者想要做一个类似QQ一样当程序崩溃后,会弹出一个窗口提示,并发送异常报告可以参考我的另外一篇博文,做出来的弹窗如图:这里写图片描述

整体的流程:

进程外 :

客户端Crash->HandleException->writeMinidumpWithException->requestDump(请求服务端生成dump)->signalCrashEventAndWait

服务端SetEvent(crash_Event)->ReadProcessMemory(客户端的exception_pointer)

windows版本下breakpad的崩溃捕获机制就是调用了Windows下捕获结构化异常的Api:SetUnhandledExceptionFilter。
另外两种C++运行库提供的崩溃,一种是使用_set_purecall_handler捕获纯虚函数调用产生的崩溃,还有一种是使用_set_invalid_parameter_handler捕获错误的参数调用产生的崩溃。

源码:

    if (handler_types & HANDLER_EXCEPTION)
      previous_filter_ = SetUnhandledExceptionFilter(HandleException);

    /*LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter(_In_LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter);
    参数:lpTopLevelExceptionFilter ,函数指针。当异常发生时,且程序不处于调试模式(在vs或者别的调试器里运行)则首先调用该函数。*/



#if _MSC_VER >= 1400  // MSVC 2005/8
    if (handler_types & HANDLER_INVALID_PARAMETER)
      previous_iph_ = _set_invalid_parameter_handler(HandleInvalidParameter);
#endif  // _MSC_VER >= 1400

    if (handler_types & HANDLER_PURECALL)
      previous_pch_ = _set_purecall_handler(HandlePureVirtualCall);

值得注意的是:在我测试的过程中,发现breakpad无法稳定地捕获由于数组越界或者容器index越界等导致的程序崩溃,然后就去查找了一下原因,任然没有得到一个比较统一的合理的解释,我自己的理解是类似数组越界等异常通常是引起缓冲区越界而导致程序崩溃,类似breakpad中采用setUnhandleExceptionFilter本身就无法稳定地捕获这些异常,在网上查找类似案例原因的时候,很多人也是这么解释的,类似buffer overflow不适用于采用异常处理,它的破坏通常是不可预测的。关于这个,如果哪位大牛有好的见解或解决方案,还请不吝赐教。另外,我多次重复地手动触发测试数组越界以及容器越界之类异常导致的程序崩溃,我写的server端偶尔也能捕获,但是将生成的dmp文件放在VS里面进行调试的时候,都无法定位到引起程序的代码节点。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:2464次
    • 积分:183
    • 等级:
    • 排名:千里之外
    • 原创:16篇
    • 转载:1篇
    • 译文:0篇
    • 评论:1条
    文章分类
    最新评论