Analyzing Segmentation fault Core Dump (gdb)

Question

I am getting following segmentation faults while running a Linux based application on imax6q custom hardware design. I backtraced the core dump using Linux GDB and following you can see those core dumps.

The kernel I'm using - 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) Those core dumps are directed to following source files. But I couldn't find those file in the above Linux-boundary 4.1.15 kernel build. What are they referring to? To overcome this problem what do you suggest?

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) I could find a file called gc_hal_kernel_hardware.c in my kernel build. So is this the file the gdb back traced log is pointing out? Do you have any idea of this kind of segmentation faults?

Take the directory you found gc_hal_kernel_hardware.c in and use it in the dir command directly in GDB like so: dir theDirectory — Bernd Elkemann
Run the gdb bt command and look at the part of the stack that includes code that you wrote (or that you're in a position to fix). — Mark Plotnick

Basile Starynkevitch Basile Starynkevitch · Accepted Answer · 2018-06-06T04:35:48

Read documentation of gdb, notably 9.5 Specifying Source Directories. Since you have a core dump it is some user-space application which crashes (not the kernel; the kernel is supposed to never crash, and when it unfortunately does, you could have a frozen system). See also signal(7). Your gc_hal_user_texture.c belongs to that crashing application, or to some library used by it.

You might use file(1) to find out which program produces that core. Run file core. See also core(5) & proc(5).

Be sure to compile that program with DWARF debug info and all warnings, so gcc -g -Wall -Wextra

Read Operating Systems: Three Easy Pieces to understand the principles (and difference between user-space code and operating system kernel code).

But I couldn't find those file in the above Linux-boundary 4.1.15 kernel build. What are they referring to?

These gc_hal_user_texture.c ... src/glcore/gc_es_api.c files refer to some application or library source code (of course they are not kernel source files).

Analyzing Segmentation fault Core Dump (gdb)

1 Answers