OpenHarmony稳定性测试问题定界思路

 

一、前言

在OpenHarmony稳定性测试过程中，通过测试工具对开发板进行长时间稳定性压测后，会生成大量jscrash、cppcrash、appfreeze等问题，在对该类问题进行分类、去重之后，接下来就要对问题进行定界，根据定界结果分派到对应责任人进行分析解决。

 

二、工具介绍

addr2line是专门解析定界cppcrash和appfreeze的工具。

 

三、文件解析

1、前期准备

使用addr2line之前，需要将欲解析的cppcrash和appfreeze文件对应版本的lib.unstripped copy到addr2line所在文件夹，lib.unstripped所在目录为\out\rk3568\lib.unstripped（以RK3568产品源码路径为例）

2、cppcrash文件解析（appfreeze文件同理）

将cppcrash文件复制到addr2line文件夹中：

在addr2line脚本下cmd，并执行以下命令：

python addr2line.py cppcrash-533-1681584915137

其中cppcrash-360-1684844261615是刚复制进来的cppcrash文件名。

执行之后，会在addr2line文件夹下生成processd开头的文件：

打开该文件会发现，已将cppcrash文件中的符号表定位至具体的代码行：

3、问题定位

1）cppcrash问题参考

a、原始崩溃so及其分类依据：# 开头的行，从 # 00 的那一行一直到第一个非C库so的那一行，根据他们的so名及其行数；如右图红框所示内容，可以直接以so名到该行尾为判断依据；

C库so判断依据：该so含有下面任一字段，并且下一个字符不是字母：

['libc.so', 'libc++', 'glibc', 'musl', 'bionic', 'libutils']

如果找不到非C库的so，那么归类为无效so。

如果不符合下面2-4的规则，那么，第一个非C库的so，就是崩溃栈，就找相应责任人。

 

 b、多线程：当第一个非c库so是ark相关的so，并且是主动abort时，崩溃so为ark后面的非ark、非C库的so

 c、libace_napi：如果问题so是libace_napi开头的，那么跳过ace相关的so，再向下找到/system/lib/module/或/system/lib64/module/开头的那个so作为责任归属

d、# 开头的某一行，如果它的地址后面为空，或者包含下面任意一个字符串，则跳过该行继续向下寻找。如果找不到有效的so，并且出现此种情况，那么归类为DFX问题。

 

['[anon:libc_malloc]', 'Unknown', '[anon:.bss]', '[heap]', '[stack]']

5、Maps之前如果没有 # 开头的行，归类为异常，Maps以后的so不看

6、其他：如果进程名包含下列任一进程，则归类为关键进程：["foundation", "render_service"]；

如果进程名包含下列任一字符串，则为测试用例，只有没有崩溃so或者找不到责任人的测试用例才归类为测试用例：

['test', 'acts', 'ceshi']

jscrash

1、Module name和Stacktrace后面第一个调用栈的名字

appfreeze

1、MSG:Blocked thread id，根据 thread id 找到下面相同的 Tid ，然后用分析cppcrash的方法去分析该Tid下 # 开头的行

2、若找不到该Tid，则根据包名PACKAGE_NAME和Stacktrace后面第一个调用栈的名字

3、过滤测试用例（含'ceshi', 'test', 'ix'，可在originAppfreeze.py第98行修改过滤的关键字）