gdb 解析NE
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了gdb 解析NE相关的知识,希望对你有一定的参考价值。
参考技术A 1.例如:如下log
7-24 19:53:39.572849 9258 9258 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
07-24 19:53:39.573010 9258 9258 F DEBUG : Build fingerprint: 'Gigaset/GS270_plus/Gigaset_GS270_plus:8.1.0/O11019/1532324320:user/release-keys'
-24 19:53:39.573042 9258 9258 F DEBUG : Revision: '0'
07-24 19:53:39.573076 9258 9258 F DEBUG : ABI: 'arm64'
07-24 19:53:39.573109 9258 9258 F DEBUG : pid: 6840, tid: 6880, name: RenderThread >>> com.google.android.contacts <<<
07-24 19:53:39.573147 9258 9258 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
07-24 19:53:39.581264 9258 9258 F DEBUG : Abort message: 'Failed to set damage region on surface 0x79981eaa40, error=EGL_SUCCESS'
07-24 19:53:39.581406 9258 9258 F DEBUG : x0 0000000000000000 x1 0000000000001ae0 x2 0000000000000006 x3 0000000000000008
07-24 19:53:39.581446 9258 9258 F DEBUG : x4 003c232f3e0e0402 x5 003c232f3e0e0402 x6 003c232f3e0e0402 x7 02040e3e2f233c00
07-24 19:53:39.581469 9258 9258 F DEBUG : x8 0000000000000083 x9 0000000010000000 x10 0000007997ffe6a0 x11 0000000000000001
07-24 19:53:39.581491 9258 9258 F DEBUG : x12 0000007997ffe7c0 x13 0000000000000000 x14 ff00000000000000 x15 003c232f3e0e0402
07-24 19:53:39.581532 9258 9258 F DEBUG : x16 0000007a35992fa8 x17 0000007a337396ac x18 0000000000000438 x19 0000000000001ab8
07-24 19:53:39.581557 9258 9258 F DEBUG : x20 0000000000001ae0 x21 0000000000000083 x22 00000079995e0b70 x23 00000079982213d8
07-24 19:53:39.581579 9258 9258 F DEBUG : x24 000000799821d688 x25 000000799821d61c x26 0000007997fff1f8 x27 0000007997fff1e0
07-24 19:53:39.581599 9258 9258 F DEBUG : x28 0000007997fff300 x29 0000007997ffe6e0 x30 0000007a336ee76c
07-24 19:53:39.581619 9258 9258 F DEBUG : sp 0000007997ffe6a0 pc 0000007a336ee794 pstate 0000000060000000
07-24 19:53:39.641034 9258 9258 F DEBUG : 07-24 19:53:39.641034 9258 9258 F DEBUG : backtrace:
07-24 19:53:39.641125 9258 9258 F DEBUG : #00 pc 000000000001d794 /system/lib64/libc.so (abort+120)
07-24 19:53:39.641150 9258 9258 F DEBUG : #01 pc 0000000000007f08 /system/lib64/liblog.so (__android_log_assert+296)
07-24 19:53:39.641178 9258 9258 F DEBUG : #02 pc 000000000006ca70 /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::damageFrame(android::uirenderer::renderthread::Frame const&, SkRect const&)+252)
07-24 19:53:39.641221 9258 9258 F DEBUG : #03 pc 00000000000697ac /system/lib64/libhwui.so (android::uirenderer::renderthread::OpenGLPipeline::draw(android::uirenderer::renderthread::Frame const&, SkRect const&, SkRect const&, android::uirenderer::FrameBuilder::LightGeometry const&, android::uirenderer::LayerUpdateQueue*, android::uirenderer::Rect const&, bool, bool, android::uirenderer::BakedOpRenderer::LightInfo const&, std::__1::vector, std::__1::allocator
2 找到对应版本的symbols 文件
3 用gdb 一行的解析
file 文件(window 注意 路径为 ./Desktop/release/libc.so. )
disassemble 地址(转换为0X )
info line
GDB再学习(11):如何生成Core文件
前面简单介绍了GDB相关的调试经验,但是在资源有限的嵌入式设备中,很难跑的了GDB ,因此就需要程序异常时候生成的core文件来解析程序的堆栈信息,这时候就需要对linux系统进行一些设置,用于程序异常时候可以生成core文件。
1 确认core文件开关是否开启
我们输入指令ulimit -a
# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 7735
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 7735
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
可以看到上面有一行
core file size (blocks, -c) 0
0表示core文件的大小为0,即没有打开。
因此我们可以使用指令 ulimit -c [kbytes] 来设置生成core文件的最大大小。
也可以使用 ulimit -c unlimited表示不限制core的大小。
注意:如果不限制大小,在嵌入式设备上最好确认core文件的生成路径的空间大小,否则可能生成的core过大,超过flash空间。一般可以将路径设置到SD卡或者NFS挂载到电脑路径下最好。
2 修改core生成路径和文件格式
默认生成的core的名字为core 路径为程序运行的路径。因此我们可以通过修改/proc/sys/kernel/core_pattern中参数来修改生成的路径和文件的格式。
如下:
echo "/tmp/core-%c-%e-%g-%h-%p-%s-%t-%u" > /proc/sys/kernel/core_pattern
代表生成的路径为/tmp目录,格式为core-%e-%p-%t,具体参数含义如下:
指令 | 说明 |
---|---|
%c | 文件的大小上限 |
%e | 程序的名字 |
%g | 程序进程组ID |
%p | 程序的ID |
%h | 主机名 |
%s | 导致本次coredump的信号 |
%t | 存储时间(UTC时间) |
%u | 进程用户ID |
比如运行前面的示例程序生成的core文件
-rw------- 1 root root 17342464 11月 17 19:25 /tmp/core-18446744073709551615-test_gdb-0-st-22862-11-1605612306-0
以上是关于gdb 解析NE的主要内容,如果未能解决你的问题,请参考以下文章