openharmonyinsight/ohos-issue-graphics-sysfreeze-analysis

任务与边界

解决的问题

分析 OpenHarmony 图形相关模块的 Sysfreeze 日志，诊断进程冻结和线程阻塞问题的根本原因。

输入

• Sysfreeze/Appfreeze 日志文件
• 相关源码（code/ 目录）
• 带符号表的 so 文件（lib.unstripped/ 目录）
• 可选：hilog 和 hilog_kmsg 日志

输出

• 故障类型确认
• 阻塞链路径
• 根本原因分析
• 优化建议

不适用情形

• 纯性能优化问题（无阻塞）
• 应用层逻辑错误（无系统级阻塞）
• 非图形模块相关调用栈的freeze问题
• 日志信息严重缺失无法分析

前置条件

用户环境提供 llvm 工具（llvm-readelf/llvm-addr2line/llvm-objdump 等）。

触发信号

• 用户要求分析 sysfreeze、appfreeze 日志
• 出现 SERVICE_BLOCK 或 THREAD_BLOCK 故障
• 需要追踪线程阻塞链和死锁
• 需要解析任务队列和资源状态
• 关键词：进程卡住、线程阻塞、死锁、freeze、block

前置检查

确认日志完整性

• 检查是否存在两次抓栈信息（SERVICE_WARNING/SERVICE_BLOCK 或 THREAD_BLOCK_3S/THREAD_BLOCK_6S）
• 确认 TIMESTAMP、TID 等关键字段存在

确认符号表可用

• 检查 lib.unstripped/ 目录是否存在带符号表的 so
• 解析命令：llvm-addr2line -Cfpie path/to/so offset
• 注意：ld-musl-xxx.so 即 libc.so

执行策略

1. 基本信息分析

确认故障类型

• 检查 Reason 字段，确认是 SERVICE_BLOCK 还是 THREAD_BLOCK
• 理解对应问题的检测原理和阈值

记录关键信息

• TIMESTAMP：故障发生时刻，用于在 hilog 日志中锁定时间范围
• TID：发生问题的线程 ID，问题分析从此线程开始

查看整机资源状态

• ReclaimAvailBuffer：整机剩余可用内存，判断是否低内存问题
  • 注意内存信息抓取时间，如果在 freeze 时间后则不具参考价值
• ThermalLevel info：热等级 ≥ 5 时，系统可能受热限频影响性能
• 如果存在整机资源问题且业务分析无异常，可优先考虑问题与之相关

2. 任务队列分析

分析当前任务

查看两次检测（SERVICE_WARNING/SERVICE_BLOCK，或 THREAD_BLOCK_3S/THREAD_BLOCK_6S）的 Current Running 任务：

• 如果两次检测任务相同：同一任务阻塞
• 如果两次检测任务不同：根据任务队列信息分析耗时较长的任务

验证时间合理性

假设最后一个 watchdog 任务在 T 时刻提交：

• 第一次抓栈：SERVICE_WARNING 预期时间 T+5s，THREAD_BLOCK_3S 预期时间 T+3s
• 第二次抓栈：SERVICE_BLOCK 预期时间 T+10s，THREAD_BLOCK_6S 预期时间 T+6s
• 如果实际时间与预期时间差异较大：DFX 抓取有时间偏差，可能存在低内存/高负载等整机问题

分析任务队列

检查各优先级任务队列（VIP、Immediate、High、Low、Idle），重点关注：

• 任务提交时间
• 任务执行时间（trigger time 开始，completeTime 完成）
• 任务优先级
• 任务提交者
• 任务名称

3. 阻塞链跟踪

分析前先问自己三个问题：

1. 阻塞类型是什么？ — 栈顶函数是等锁、等信号量、还是 IPC 调用？
2. 阻塞源头在哪里？ — 资源被谁持有，IPC 对端是谁？
3. 阻塞链是否闭合？ — 能追溯到不阻塞的最终线程吗？

根据两次抓取的调用栈分析线程阻塞关系，分析时必须解栈。

重要：分析从基本信息中的 Tid:<TID> 线程开始。

调用栈对比

对比两次抓栈

• 两次抓栈一致：卡在同一业务
• 两次抓栈不一致：可能抓到不同任务的两次瞬时栈，或者未卡住但执行时间长的同一任务

分析线程状态（如果有）

• 查看线程状态字段：state、utime、stime、priority、nice、clk
• 关键判断：
  • 如果线程栈顶未等待资源/陷入内核但未处于执行状态（state=S）：可能是整机问题（低内存/IO 问题等）导致
  • 结合 utime/stime 和抓栈时间间隔，确定线程在用户态和内核态的执行时长
  • 对比两次抓栈的运行时间，如果无变化则说明线程未被调度

分析堆栈阻塞模式

识别栈顶的阻塞函数，参考 常见阻塞模式

阻塞链分析

识别阻塞类型

• 根据栈顶函数判断阻塞原因（等锁、信号量、IPC 调用等）

查找阻塞源头

• 栈顶等锁/信号量/条件变量：找到当前等待资源的持有线程或触发线程
• 栈顶为 IPC 调用：找到 IPC 对端线程
• 阻塞线程通常与被阻塞栈顶在同一 so 或同一个类的业务中

递归分析阻塞

• 如果阻塞线程也处于阻塞条件，继续分析阻塞其的线程
• 直到找到不处于阻塞状态的线程，作为最终问题线程

如果是IPC 阻塞处理

• 查看 BinderCatcher 信息，获取源为 当前进程号:当前线程号 的同步调用
• 查看阻塞时间
• 查看 对端进程号:对端线程号 信息，查找 PeerBinder Stacktrace 中对应的进程抓栈
• 从对端线程号对应的线程开始分析阻塞情况

4. 流水日志分析（如果有日志）

获取流水日志

• 检查是否存在 hilog 和 hilog_kmsg 文件

分析流水日志

• 分析在 TIMESTAMP 问题发生时间附近的日志
• 识别可能相关的异常日志，参考 常见流水日志
• 识别业务场景和操作流程

5. 综合分析与报告

确定根本原因

• 综合堆栈信息、任务队列、线程状态、资源状态
• 判断问题的相关业务信息，或者相关的整机问题

绘制阻塞路径

• 描述从阻塞线程开始到最终问题线程的完整调用链
• 标注关键阻塞点和等待的资源

分析业务信息

• 解析堆栈对应的业务代码
• 结合关键日志，说明卡住的业务场景和操作流程

生成分析报告

• 故障分析总结
• 阻塞路径分析
• 问题根本原因（如果结果不完整，则给出下一步排查方向）
• 建议优化方向

重要：完成分析后生成报告并保存到文档。

禁止做法

不要跳过解栈步骤

• 错误做法：直接根据 so 名称和偏移猜测业务逻辑
• 原因：函数名和偏移对应的代码行号是定位问题的关键，不解栈会导致分析方向错误

不要忽略整机资源状态

• 错误做法：只关注业务堆栈，忽略内存、温度等资源信息
• 原因：低内存、过热等整机问题可能是真正的根因

不要孤立分析单个线程

• 错误做法：只分析问题线程的堆栈，不追溯阻塞链
• 原因：阻塞通常是由锁竞争或 IPC 调用链导致，需要找到最终的问题线程

不要在信息不足时强行下结论

• 错误做法：缺少符号表或日志时仍给出确定的根因
• 原因：错误的分析结论会误导后续排查方向

不要忽略时间信息

• 错误做法：忽略两次抓栈的时间差、任务提交时间
• 原因：时间信息可判断是否为瞬时阻塞、DFX 抓取是否正常

异常与回退

信息不足时的处理

| 缺失信息 | 处理方式 | |----------|----------| | 符号表不存在 | 指出需要哪些 so 的符号表，无法精确定位代码行号 | | 只有一次抓栈 | 说明缺少对比信息，无法判断是否同一任务阻塞 | | hilog 缺失 | 仅依赖堆栈和任务队列分析，报告中标注日志缺失 | | BinderCatcher 缺失 | IPC 阻塞分析受限，尝试从堆栈推断对端 |

解栈失败时的处理

• 检查 so 文件路径是否正确
• 确认偏移量是否有效（十六进制格式）
• 使用 llvm-readelf 验证 so 是否包含符号表
• 如果确认无符号表，在报告中明确标注

阻塞链无法闭合时的处理

• 检查是否有 IPC 跨进程调用（需要查看对端进程）
• 考虑内核态阻塞（如 IO 等待）
• 在报告中说明阻塞链在哪个节点中断，给出下一步排查方向

整机问题优先级判断

当同时存在业务问题和整机问题时：

• 如果整机资源严重异常（如内存接近耗尽），优先报告整机问题
• 如果整机资源轻微异常但业务有明显阻塞逻辑，优先分析业务问题
• 如果无法确定，在报告中同时列出两种可能性

参考资料

何时读取：

• 常见阻塞模式：识别栈顶阻塞函数时读取（如 pthread_mutex_timedlock_inner、pthread_cond_timedwait）
• 常见流水日志：分析 hilog 异常日志时读取（如 GetSaWrap、vsync signal）

何时不要读取：

• 仅做基本信息分析（故障类型、整机资源），不需要加载任何参考文件
• 阻塞链已明确且无需识别阻塞模式，不要加载 blocking-patterns.md
• 无 hilog 文件或日志分析已完成，不要加载 hilog-refernce.md