C++的异常机制导致的crash问题

问题背景

最近工作中遇到了一个非常奇怪的crash问题,反反复复分析了好久。由于保密原因,这里只记录一下分析思路,不会涉及到代码。

初步log分析

tombstone显示这是一个abort:

Cmdline: /vendor/bin/hw/vendor.qti.camera.provider@2.7-service_64
pid: 1189, tid: 20934, name: HwBinder:1189_5 >>> /vendor/bin/hw/vendor.qti.camera.provider@2.7-service_64 <<<
uid: 1047
tagged_addr_ctrl: 0000000000000001
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'terminating with uncaught exception of type NSt6__ndk112system_errorE'
x0 0000000000000000 x1 00000000000051c6 x2 0000000000000006 x3 0000006fefc1b180
x4 736f646277641f73 x5 736f646277641f73 x6 736f646277641f73 x7 7f7f7f7f7f7f7f7f
x8 00000000000000f0 x9 883ddec157d9b7a4 x10 0000000000000000 x11 ffffff80ffffffdf
x12 0000000000000001 x13 000000007fffffff x14 0000000000097c44 x15 000000082449409b
x16 0000007197d09d30 x17 0000007197ce3650 x18 0000006fd46cc000 x19 00000000000004a5
x20 00000000000051c6 x21 00000000ffffffff x22 0000007197d0d210 x23 0000006fefc1b2f0
x24 0000006fefc1b2b0 x25 0000000000000048 x26 b40000708493eb00 x27 b40000708636d880
x28 b40000708636d880 x29 0000006fefc1b200
lr 0000007197c939fc sp 0000006fefc1b160 pc 0000007197c93a28 pst 0000000000001000

backtrace:
#00 pc 000000000008aa28 /apex/com.android.runtime/lib64/bionic/libc.so (abort+168) (BuildId: 94065bf91428f6ae9fb310c478171302)
#01 pc 000000000004911c /apex/com.android.vndk.v31/lib64/libc++.so (abort_message+252) (BuildId: 3800ebf760648abf274c4f36afc38008)
#02 pc 0000000000049310 /apex/com.android.vndk.v31/lib64/libc++.so (demangling_terminate_handler()+240) (BuildId: 3800ebf760648abf274c4f36afc38008)
#03 pc 0000000000049ecc /apex/com.android.vndk.v31/lib64/libc++.so (std::__terminate(void (*)())+16) (BuildId: 3800ebf760648abf274c4f36afc38008)
#04 pc 0000000000049e64 /apex/com.android.vndk.v31/lib64/libc++.so (std::terminate()+56) (BuildId: 3800ebf760648abf274c4f36afc38008)
#05 pc 000000000058694c /vendor/lib64/hw/camera.qcom.so (__clang_call_terminate+12) (BuildId: 37fa0aa7aeb902db4b7d78f719568eb3)
#06 pc 0000000000eb2190 /vendor/lib64/hw/camera.qcom.so (CamX::MiTrackerNode::~MiTrackerNode()+680) (BuildId: 37fa0aa7aeb902db4b7d78f719568eb3)
#07 pc 0000000000eb21ac /vendor/lib64/hw/camera.qcom.so (CamX::MiTrackerNode::~MiTrackerNode()+20) (BuildId: 37fa0aa7aeb902db4b7d78f719568eb3)
#08 pc 0000000000f9a448 /vendor/lib64/hw/camera.qcom.so (CamX::Node::Destroy()+5392) (BuildId: 37fa0aa7aeb902db4b7d78f719568eb3)
#09 pc 0000000000fd72e4 /vendor/lib64/hw/camera.qcom.so (CamX::Pipeline::DestroyNodes()+108) (BuildId: 37fa0aa7aeb902db4b7d78f719568eb3)

第一反应是通过addr2line找到异常发生的点:

 addr2line -Cife out/target/product/zeus/symbols/vendor/lib64/hw/camera.qcom.so 0000000000eb2190 ~MiTrackerNode vendor/qcom/proprietary/camx-common/../camx/src/swl/mitrackaf/camxmitrackafnode.cpp:229 (discriminator 8) 

 addr2line -Cife out/target/product/zeus/symbols/vendor/lib64/hw/camera.qcom.so 0000000000eb21ac ~MiTrackerNode vendor/qcom/proprietary/camx-common/../camx/src/swl/mitrackaf/camxmitrackafnode.cpp:175

解析地址,发现addr2line的结果指向了函数的两个括号处{}:


/// Node::~Node

MiTrackerNode::~MiTrackerNode()
{ //175行
    CamxResult result = CamxResultSuccess;
 
    CAMX_LOG_VERBOSE(CamxLogGroupTracker,"m_algoInitFlag %d m_pMiTracker %p cameraId %d",
            m_algoInitFlag,m_pMiTracker,m_cameraInfo.cameraId);
    CamxTime exitstartTime;
    CamxTime exitendTime;
    OsUtils::GetTime(&exitstartTime);
    if (pthread_join(m_hInitThread, NULL) != 0)
    {
        CAMX_LOG_INFO(CamxLogGroupTracker,"m_hInitThread dead already\n");
    }

   //
    

   .................................

   //



OsUtils::GetTime(&exitendTime);
    CAMX_LOG_VERBOSE(CamxLogGroupTracker, " ~MiTrackerNode time = %d ms",
        (OsUtils::CamxTimeToMillis(&exitendTime) - OsUtils::CamxTimeToMillis(&exitstartTime)));
} //229行

意思是第一行代码的执行就出了问题?听起来不太合理,看来addr2line不能帮忙定位到问题。

使用objdump分析

换到objdump看下这段代码到底有什么特别的地方,使得addr2line不能工作。以下是通过aarch64-linux-gnu-objdump.exe -D E:\log\camera.qcom.so | less定位到的出问题附近的汇编代码块:

根据上面的分析,分别对这几个地址做解码:

E:\log\camlog-1112150636>D:\tools\gcc-linaro-7.5.0-2019.12-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-addr2line.exe -e E:\log\camera.qcom.so 0xeb2108
vendor/qcom/proprietary/camx-common/../camx/src/swl/mitrackaf/camxmitrackafnode.cpp:227 (discriminator 14)

E:\log\camlog-1112150636>D:\tools\gcc-linaro-7.5.0-2019.12-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-addr2line.exe -e E:\log\camera.qcom.so 0xeb20c4
vendor/qcom/proprietary/camx-api/camx/utils/camxosutils.h:1518 (discriminator 4)

E:\log\camlog-1112150636>D:\tools\gcc-linaro-7.5.0-2019.12-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-addr2line.exe -e E:\log\camera.qcom.so 0xeb20d8
vendor/qcom/proprietary/camx-api/camx/utils/camxosutils.h:1518 (discriminator 4)

E:\log\camlog-1112150636>D:\tools\gcc-linaro-7.5.0-2019.12-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-addr2line.exe -e E:\log\camera.qcom.so 0xeb2150
vendor/qcom/proprietary/camx-common/../camx/src/swl/mitrackaf/camxmitrackafnode.cpp:?

指向的代码分别是这些:

static UINT32 CamxTimeToMillis(
        CamxTime*   pTime)
{
    return (pTime == NULL) ? 0 : ((1000 * pTime->seconds) + ((pTime->nanoSeconds) / 1000000L));//这行代码就是vendor/qcom/proprietary/camx-api/camx/utils/camxosutils.h:1518
}
 

/// MiTrackerNode::~MiTrackerNode

MiTrackerNode::~MiTrackerNode()
{ //175行
 
    OsUtils::GetTime(&exitendTime);
    CAMX_LOG_VERBOSE(CamxLogGroupTracker, " ~MiTrackerNode time = %d ms",    //这行代码就是vendor/qcom/proprietary/camx-common/../camx/src/swl/mitrackaf/camxmitrackafnode.cpp:227
        (OsUtils::CamxTimeToMillis(&exitendTime) - OsUtils::CamxTimeToMillis(&exitstartTime)));
} //229行

由此可以推测,这个terminate的源头很可能就在这个CamxTimeToMillis的调用上。具体产生的原因暂不明了,但删除这行代码后,这个错误就消失了。

复现后继续分析

不久,问题再次复现,并且这一次现象变得更加奇怪了。

这一次的backtrace跟上一次一模一样:

11-09 12:15:57.206 29142 29142 F DEBUG : pid: 12760, tid: 28582, name: HwBinder:12760_ >>> /vendor/bin/hw/vendor.qti.camera.provider@2.7-service_64 <<<
11-09 12:15:57.207 29142 29142 F DEBUG : uid: 1047
11-09 12:15:57.207 29142 29142 F DEBUG : tagged_addr_ctrl: 0000000000000001
11-09 12:15:57.207 29142 29142 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
11-09 12:15:57.207 29142 29142 F DEBUG : Abort message: 'terminating with uncaught exception of type NSt6__ndk112system_errorE'
11-09 12:15:57.207 29142 29142 F DEBUG : x0 0000000000000000 x1 0000000000006fa6 x2 0000000000000006 x3 0000007559da01a0
11-09 12:15:57.207 29142 29142 F DEBUG : x4 736f646277641f73 x5 736f646277641f73 x6 736f646277641f73 x7 7f7f7f7f7f7f7f7f
11-09 12:15:57.208 29142 29142 F DEBUG : x8 00000000000000f0 x9 54725e8097ae4b13 x10 0000000000000000 x11 ffffff80ffffffdf
11-09 12:15:57.208 29142 29142 F DEBUG : x12 0000000000000001 x13 000000007fffffff x14 000000000037366a x15 000000258cff67cb
11-09 12:15:57.208 29142 29142 F DEBUG : x16 00000079b89f9060 x17 00000079b89d54e0 x18 000000752fcf4000 x19 00000000000031d8
11-09 12:15:57.208 29142 29142 F DEBUG : x20 0000000000006fa6 x21 00000000ffffffff x22 00000079b89fb350 x23 0000007559da0310
11-09 12:15:57.208 29142 29142 F DEBUG : x24 0000007559da02d0 x25 0000000000000048 x26 b4000078083bda60 x27 b4000078287262c0
11-09 12:15:57.208 29142 29142 F DEBUG : x28 b4000078287262c0 x29 0000007559da0220
11-09 12:15:57.208 29142 29142 F DEBUG : lr 00000079b898583c sp 0000007559da0180 pc 00000079b8985868 pst 0000000000001000
11-09 12:15:57.209 29142 29142 F DEBUG : backtrace:
11-09 12:15:57.209 29142 29142 F DEBUG : #00 pc 0000000000051868 /apex/com.android.runtime/lib64/bionic/libc.so (abort+168) (BuildId: b15ac47006c5c2933d0526c330c56105)
11-09 12:15:57.209 29142 29142 F DEBUG : #01 pc 000000000004911c /apex/com.android.vndk.v31/lib64/libc++.so (abort_message+252) (BuildId: 3800ebf760648abf274c4f36afc38008)
11-09 12:15:57.209 29142 29142 F DEBUG : #02 pc 0000000000049310 /apex/com.android.vndk.v31/lib64/libc++.so (demangling_terminate_handler()+240) (BuildId: 3800ebf760648abf274c4f36afc38008)
11-09 12:15:57.209 29142 29142 F DEBUG : #03 pc 0000000000049ecc /apex/com.android.vndk.v31/lib64/libc++.so (std::__terminate(void (*)())+16) (BuildId: 3800ebf760648abf274c4f36afc38008)
11-09 12:15:57.209 29142 29142 F DEBUG : #04 pc 0000000000049e64 /apex/com.android.vndk.v31/lib64/libc++.so (std::terminate()+56) (BuildId: 3800ebf760648abf274c4f36afc38008)
11-09 12:15:57.209 29142 29142 F DEBUG : #05 pc 00000000005afcf4 /vendor/lib64/hw/camera.qcom.so (__clang_call_terminate+12) (BuildId: 882d57000dbf93c8161629a99404f1c4)
11-09 12:15:57.209 29142 29142 F DEBUG : #06 pc 0000000000f97fec /vendor/lib64/hw/camera.qcom.so (CamX::MiTrackerNode::~MiTrackerNode()+444) (BuildId: 882d57000dbf93c8161629a99404f1c4)
11-09 12:15:57.209 29142 29142 F DEBUG : #07 pc 0000000000f98004 /vendor/lib64/hw/camera.qcom.so (CamX::MiTrackerNode::~MiTrackerNode()+20) (BuildId: 882d57000dbf93c8161629a99404f1c4)
11-09 12:15:57.209 29142 29142 F DEBUG : #08 pc 0000000001082d10 /vendor/lib64/hw/camera.qcom.so (CamX::Node::Destroy()+5440) (BuildId: 882d57000dbf93c8161629a99404f1c4)

同样addr2line也是指向CamX::MiTrackerNode::~MiTrackerNode()的开头。所以addr2line对于这个问题也同样不好使。更糟糕的是,这一次连objdump也不好使了:

死磕问题

山穷水尽的情况下只能反过来思考,__clang_call_terminate这个函数在什么情况下会被调用到。opengrok一搜,调用这个函数的地方太多了。只好再看下这个abort发生前的log信息,下面几行log让我像突然触电一样:

11-09 12:15:51.979 12760 28582 W libc : invalid pthread_t (0) passed to pthread_join
11-09 12:15:52.067 12760 28582 E libc++abi: terminating with uncaught exception of type NSt6__ndk112system_errorE
11-09 12:15:52.206 12760 28582 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 28582 (HwBinder:12760_), pid 12760 (vendor.qti.came)

第一行提示了pthread处出现了一个警告,紧接着出现一个关键字:uncaught exception,这不就是C++中的exception机制吗?当一个exception没有通过try catch捕获的时候,就会出现这种情况。

C++的exception机制包括这几部分:

1.  对于每个 catch 语句的存在,编译器会在其所在的函数末尾加上一些特殊信息,包括当前函数可以捕获的异常表,以及清理表(cleanup table)。在进行栈展开时,会调用 libstdc++ 提供的特殊函数(称为 personality routine),会检查栈上的所有函数哪个异常可以被捕获。如果其调用栈上没有任何一个函数安装了try-catch,那么就会转入默认的处理handler。

2. 类的析构函数如果没有try-catch语句,编译器会自动在这个析构函数最后面放一个默认的处理handler,也就是terminate。在出现异常的时候,直接跳转到这个默认处理handler里面执行。这也是为什么在这一次的汇编代码里面看不到有地方跳转到terminate,偏偏又执行到这里的原因。

详细介绍:C++ 异常是如何实现的 - 知乎

到这问题就比较清晰了,MiTrackerNode::~MiTrackerNode函数内部某个地方很可能发生了exception,而这个函数又没有安装try-catch,这导致exception的默认处理方法terminate被执行了。所以要找到问题,就需要在这个函数里面安装一个try-catch预语句,涵盖整个析构函数。这样就可以轻易抓到exception发生的源头,从而解决问题。目前正在等待问题复现并做最终的解决方案。我的预感是离问题解决也就是一步之遥了。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mfbz.cn/a/5236.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

HAL库(STM32CubeMX)之外部中断(STM32F103C8T6)

系列文章目录 HAL库&#xff08;STM32CubeMX&#xff09;——ADC学习总结&#xff08;包含单次/连续模式下的轮询/中断/DMA&#xff09;&#xff08;蓝桥杯STM32G431RBT6&#xff09; HAL库(STM32CubeMX)——DAC学习&#xff08;STM32G431RBT6&#xff09; HAL库(STM32CubeM…

【Spring源码】讲讲Bean的生命周期

1、前言 面试官&#xff1a;“看过Spring源码吧&#xff0c;简单说说Spring中Bean的生命周期” 大神仙&#xff1a;“基本生命周期会经历实例化 -> 属性赋值 -> 初始化 -> 销毁”。 面试官&#xff1a;“......” 2、Bean的生命周期 如果是普通Bean的生命周期&am…

ZYNQ中的AXI DMA

AXI DMA简介 DMA—直接内存访问—从外设到内存或者从内存到外设&#xff0c;不干涉CPU 硬核DMA和DMA软核如何选择 硬核—内存到内存、内存到PL&#xff08;通过GP传输速率低&#xff09;、内存到IO外设软核—从PL部分将大量数据进行搬运到内存&#xff08;连接到HP速率更高&am…

【中级软件设计师】—数据结构与算法基础考点总结篇(八)

【中级软件设计师】—数据结构与算法基础考点总结篇&#xff08;八&#xff09; 课程大纲 1.1 数组 按行存储&#xff1a;a(2*53)*2 其中a表示的就是a[0][0] 1.2 稀疏矩阵 本题采用代入法&#xff0c;首先代入A0,0&#xff0c;A0,0存入的位置是M【1】&#xff0c;把i0,j0分别…

[网络原理] TCP 协议的相关特性

TCP和UDP都是传输层的协议. 文章目录1. TCP协议格式2. TCP连接及断开连接管理2.1 三次握手2.2 四次挥手3. TCP可靠性机制3.1 确认应答3.2 超时重传4. 滑动窗口5. 流量控制6. 拥塞控制7. 延迟应答8. 捎带应答9. 面向字节流10. 异常情况1. TCP协议格式 TCP的特点是有连接,可靠性…

Ceres 自动求导解析-从原理到实践

Ceres 自动求导解析-从原理到实践 文章目录Ceres 自动求导解析-从原理到实践1.0 前言2.0 Ceres求导简介3.0 Ceres 自动求导原理3.1 官方解释3.2 自我理解4.0 实践4.1 Jet 的实现4.2 多项式函数自动求导4.3 BA 问题中的自动求导Reference1.0 前言 Ceres 有一个自动求导功能&…

Java 读取Excel模板中的数据到实体类

目录一. 前提条件1.1 需求1.2 分析二. 准备2.1 自定义注解2.2 封装Excel的实体类三. 前台四. Controller层五. Service层&#x1f4aa;&#x1f4aa;&#x1f4aa;六. 效果一. 前提条件 1.1 需求 从指定的Excel模板中读取数据&#xff0c;将读取到的数据存储到数据库中。 1.2…

VBA定位文本框控件中光标位置

实例需求&#xff1a;用户窗体中有如下4个TextBox控件&#xff0c;TextBox1中已经有文字内容&#xff0c;点击【定位】按钮&#xff0c;统计TextBox1中段落数量&#xff0c;并定位TextBox1中光标位置&#xff08;箭头处&#xff09;&#xff0c;如下图所示。 示例代码如下。 P…

谈谈你对ThreadLocal的理解

谈谈你对ThreadLocal的理解 ThreadLocal是Java中的一个线程本地变量&#xff0c;它可以在多线程环境下&#xff0c;为每个线程提供独立的变量副本&#xff0c;保证了线程之间的数据隔离。ThreadLocal通常用于解决多线程共享变量的线程安全问题。 ThreadLocal通过一个ThreadLo…

第03章_基本的SELECT语句

第03章_基本的SELECT语句 &#x1f3e0;个人主页&#xff1a;shark-Gao &#x1f9d1;个人简介&#xff1a;大家好&#xff0c;我是shark-Gao&#xff0c;一个想要与大家共同进步的男人&#x1f609;&#x1f609; &#x1f389;目前状况&#xff1a;23届毕业生&#xff0c;…

【Redis】十大数据类型(上篇)

文章目录概述命令官网Key命令Redis 的过期时间设置有四种形式&#xff1a;redis字符串(String)最最常用 set key value常用命令图示多值设置 mset、mget获取指定区间范围内的值 getrange、setrange数值增减 INCR key、DECR key获取内容长度及内容追加 STRLEN key、APPEND key x…

基于Android的停车场车位预约系统app-动态计算停车时长-公告-反馈

在设计时,用现代多媒体技术对 进行存储、加载智能码、调用、对比及识别,使得进出的车辆同时处于该系统电脑的监控之下&#xff0c;创建车库管理与车牌识别两者完美结合的管理流程。 智能停车场收费管理系统是一种高效快捷、公正准确、科学经济的停车场管理手段&#xff0c;是停…

工具:dumpbin.exe : COFF DLL 动态库依赖库 :VS工具

摘要&#xff1a; 速度快&#xff0c;不会像depend.dll 那样卡顿。但是无法查看调用dll 调用的dll&#xff0c;所以不如depend.exe 好用。查看方式不如depend.exe 直观。 总结&#xff1a;** 可能不怎么用** 介绍&#xff1a; dumpbin.exe是微软二进制文件转储器。显示有关…

字节跳动软件测试岗,前两面过了,第三面被面试官吊打,结局我哭了

阎王易见&#xff0c;小鬼难缠。我一直相信这个世界上好人居多&#xff0c;但是也没想到自己也会在阴沟里翻船。我感觉自己被字节跳动的HR坑了。 在这里&#xff0c;我只想告诫大家&#xff0c;offer一定要拿到自己的手里才是真的&#xff0c;口头offer都是不牢靠的&#xff0…

Uni-Mol: A Universal 3D Molecular Representation Learning Framework

Uni-Mol: 一个通用的三维分子表示学习框架 ICLR 2023 Uni-Mol 论文&#xff1a;Uni-Mol: A Universal 3D Molecular Representation Learning Framework | OpenReview Uni-Mol 代码&#xff1a;&#xff1a;GitHub - dptech-corp/Uni-Mol: Official Repository for the Uni-Mo…

Python:《寻找整数》

问题描述 本题为填空题&#xff0c;只需要算出结果后&#xff0c;在代码中使用输出语句将所填结果输出即可。 有一个不超过 1017 的正整数 n&#xff0c;知道这个数除以 2 至 49 后的余数如下表所示&#xff0c;求这个正整数最小是多少。 运行限制 最大运行时间&#xff1a;…

辉煌优配|人民币将可直接买港股 多家港股公司申请 增设人民币柜台

3月以来&#xff0c;多家港股公司发布公告称&#xff0c;已正式提交有关增设人民币货台的请求。这意味着港交所力推的港股“港币-人民币双货台形式”进入实质性推进阶段&#xff0c;离岸人民币行将迎来愈加丰富的出资标的。 多位业内人士表明&#xff0c;树立双货台形式是港交所…

Java设计模式(十七)—— 组合模式

组合模式的定义如下&#xff1a;将对象组合成树形结构以表示“部分-整体”的层次结构&#xff0c;让用户对单个对象和组合对象的使用具有一致性。 适用组合模式的情景如下&#xff1a; 希望表示对象的“部分—整体”层次结构希望用户用一致方式处理个体和组合对象一、问题的提…

这是一篇能够教会你运营阿里巴巴国际站的文章

对于很多跨境人来说&#xff0c;运营真的是一个让人头疼的大事情。不知道要从哪个方面下手&#xff0c;不知道要往哪方面努力等等问题都是很常见的&#xff0c;所以今天龙哥就解剖一下阿里巴巴国际站的运营方法&#xff0c;简单地给大家讲一下要掌握哪些方面的知识。运营这条路…

【数据结构篇C++实现】- 哈希表

文章目录&#x1f680;一、哈希表的原理精讲&#x1f6a2;&#xff08;一&#xff09;概念&#x1f6a2;&#xff08;二&#xff09;常见哈希函数的构造方法1.直接定址法2.数字分析法3.平方取中法4.除留余数法5.随机数法&#x1f6a2;&#xff08;三&#xff09;哈希冲突与处理…
最新文章