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 1117 19:25 /tmp/core-18446744073709551615-test_gdb-0-st-22862-11-1605612306-0

以上是关于gdb 解析NE的主要内容,如果未能解决你的问题,请参考以下文章

Linux gdb调试器用法全面解析

GIS开源框架:ArcGIS文件地理数据库(GDB)解析与入库

无法解析 putextra 方法

spring源码解析前瞻

解析和更改 NSPredicate

Windows 主机名解析