现场背景：一台机器运行不久后卡死画面崩溃，可以将问题点缩小成屏幕相关排除干扰

📖 精选 ✍️ 🌶 ｜ 📅 2026-04-16 ｜ 👍 0 ｜原帖↗
#知识星球 #立芯嵌入式 #来源/立芯星球 #技术/Android #技术/Coredump #质量/普通

原帖｜ 🌶 ｜ 2026-04-16 19:39 ｜ 👍0 ｜阅读约1

现场背景：一台机器运行不久后卡死画面崩溃，可以将问题点缩小成屏幕相关排除干扰
屏幕卡死，我们可以去查看tomb 墓碑文件方便我们定位问题瞬间：
有tomb0-8文件，其中有两个是显示相关surfacefinger，着重看，报错不同
可将问题缩小为
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x5e
Abort message: 'eglSwapBuffers(0x1, 0xb84ae2f8) failed with 0x00003003'
可以将问题层级锁定在native层，搜索上面报错，找到参考文档：
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8 in tid 3687：如何定位与解决Android Native层空指针崩溃？_编程语言-CSDN问答

Android系统异常Native堆栈分析工具addr2line_android分析墓碑文件报错libsurfaceflinger.so-CSDN博客
刚好都是类似问题现象

将下载好的工具上传
整体思路：“逆向溯源”
根据墓碑文件：
使用指令：其实就是工具调用参数+对应的.so路径和坏掉的地址
aarch64-linux-android-addr2line -f -C -e
t/test_8227l/8227LGO_20190111/out/target/product/8227LGO_demo\symbols\system\lib64\libsurfaceflinger.so 000000000001e98c

//输出结果：
android::DisplayDevice::swapBuffers(android::HWComposer&) const /home/system4/MTK_5.1/CPY803_8_Volte_5.1_Int/mydroid/frameworks/native/services/surfaceflinger/DisplayDevice.cpp:285

就可以定位到源码位置

具体操作步骤：在服务器找到对应.so拉到电脑，使用电脑的addr.exe工具分析定位
可行，定位成功
.\aarch64-linux-android-addr2line.exe -f -C -e libsurfaceflinger.so 0002bdb7
补充：大概率是内存问题，但现在的情况是kmsg也会被带崩，丢失OOM的直接内核日志证据，我们现在可以将问题收敛至surfaceflinger/内存申请
那么根据资料查阅，有工具可以帮助我们查看内存占用
1.查看surfaceflinger 是否过大（framework层）
dumpsys meminfo || dumpsys meminfo surfaceflinger
2.如果内存充足，考虑是连续内存块不够导致的问题
cat /proc/meminfo | grep Cma
/system/bin/dma_buf_dump | grep -A 1 -B 1 surfaceflinger
3.内核崩溃日志报错反馈
cat /sys/fs/pstore/console-ramoops-0
三大手段应该可以辅助我们定位问题
最后给到app源码位置进行分析，发现是app某块申请内存的进程异常导致的内存泄露

相关笔记