首页 文章

分析故障核心转储(gdb)

提问于
浏览
0

我在imax6q自定义硬件设计上运行基于Linux的应用程序时遇到了分段错误 . 我使用Linux GDB回溯了核心转储,然后您可以看到这些核心转储 .

我正在使用的内核 - Linux-boundary 4.1.15

Seg fault Core dump 1

Program terminated with signal SIGSEGV, Segmentation fault.
#0 gcoTEXTURE_BindTextureEx (Texture=0x263c6c4, Target=Target@entry=0, 
Sampler=1, Sampler@entry=0, Info=Info@entry=0x23f0708, 
textureLayer=textureLayer@entry=0)
at gc_hal_user_texture.c:3804
3804 gc_hal_user_texture.c: No such file or directory.

Seg fault Core dump 2

Program terminated with signal SIGSEGV, Segmentation fault.
#0 _SetFenceCtx (fence=0x5c30d6c, head=0x5c2ab74) at 
gc_hal_user_hardware.c:5752
5752 gc_hal_user_hardware.c: No such file or directory.

1)这些核心转储被定向到以下源文件 . 但我在上面的Linux边界4.1.15内核版本中找不到那些文件 . 他们指的是什么?要克服这个问题,你有什么建议?

gc_hal_user_texture.c
gc_hal_user_hardware.c
src/glcore/gc_es_draw.c:943
src/glcore/gc_es_api.c:399

2)我可以在我的内核版本中找到一个名为gc_hal_kernel_hardware.c的文件 . 这是gdb回溯跟踪日志指出的文件吗?你知道这种分段错误吗?

1 回答

  • 2

    阅读documentation of gdb,特别是9.5 Specifying Source Directories . 由于你有一个 core 转储,它是一些崩溃的应用程序user-space(不是kernel;内核应该永远不会崩溃,不幸的是,它可能会有一个冻结的系统) . 另见signal(7) . 你的 gc_hal_user_texture.c 属于那个崩溃的application,或属于它使用的某些library .

    您可以使用file(1)找出哪个程序产生 core . 运行 file core . 另见core(5)proc(5) .

    务必compile该程序带有DWARF调试信息和所有警告,所以 gcc -g -Wall -Wextra

    阅读Operating Systems: Three Easy Pieces以了解原理(以及用户空间代码和操作系统内核代码之间的区别) .

    但我在上面的Linux边界4.1.15内核版本中找不到那些文件 . 他们指的是什么?

    这些 gc_hal_user_texture.c ... src/glcore/gc_es_api.c 文件引用了一些应用程序或库源代码(当然它们不是内核源文件) .

相关问题