backtrace by SIGSEGV

Question

I'm debugging an application write in ansi C, a multiple threads program.
Sometime, in the main thread cause a SIGSEGV fault.

(gdb) backtrace full
#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) info registers
rax            0x1      1
rbx            0x0      0
rcx            0x0      0
rdx            0x2      2
rsi            0x458e7aa0       1166965408
rdi            0x0      0
rbp            0x0      0x0
rsp            0x458e7b60       0x458e7b60
r8             0x458e7b20       1166965536
r9             0x0      0
r10            0x0      0
r11            0x206    518
r12            0x2aaaac400e70   46912522686064
r13            0x2aaaac514090   46912523813008
r14            0x1      1
r15            0x18505f10       407920400
rip            0x0      0
eflags         0x10206  [ PF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x63     99
gs             0x0      0
fctrl          0x37f    895
fstat          0x0      0
ftag           0xffff   65535
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
fop            0x0      0
mxcsr          0x1f80   [ IM DM ZM OM UM PM ]
(gdb)

This information is from core file, I'm not very family with debug in Linux environment, Is there anything I can do to find where's the problem?

Edit: all of source files are compiled with flag as follow

gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/redisconnector.d" -MT"src/redisconnector.d" -o"src/redisconnector.o" "../src/redisconnector.c"

Dispose

Please, list all your compiling options and version of GCC – Gagliardi

Answer 1

Recompile the application with "-g" option;

Use Gdb not with core files, but to run entire application:

gdb --args ./application application_options

then "run" command of gdb.

Running from gdb will detect SIGSEGV, and gdb will be focused on failed thread.

Gagliardi

Answer 2

Your RIP points to 0. It's probably caused by a stack overflow. Your RBP is also 0, so the backtrace gdb command will tell you nothing.

Folkway

To add, if it's a stack overflow then you're writing past the end of an array (or string) most likely. I'd check there first. – Mindoro

@Mindoro I think you mean buffer overflow when you write past the end of an array? – Tertius

Well, it's the same thing, if your buffer is on the stack. A buffer overflow is any buffer, stack, heap, etc. A stack overflow is specifically overwriting the buffer of the stack. You can tell this is specifically a stack overflow because the instruction pointer is screwed. :) – Mindoro

@OmnipotentEntity: It could also be something overwriting the GOT, or a C++ vtable, or a pointer to a function... It's just that I have the feeling that a stack overflow is much more probable (and also RBP is 0, but does x86_64 usually get compiled with frame pointer?). – Folkway

x86_64 gets compiled with frame pointer on optimization levels 0,1,2. – Mindoro

Answer 3

Well, first you'll need to compile with debugging enabled so that your backtrace has something usable. The flag is gcc -g

Mindoro

I've already compiled it with -g3, but that's all it can show. – Dispose