2

/var/log/message:

segfault at 0 ip 00007fcd16e5853a sp 00007ffd98e37e58 error 4 in libc-2.24.so[7fcd16dc9000+195000]

addr2line -e a.out 00007fcd16e5853a

??:0

gdb bt

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fcd16e5853a in ?? ()
(gdb) bt
#0  0x00007fcd16e5853a in ?? ()
#1  0x000055f2f45fe95b in ?? ()
#2  0x000055f200000080 in ?? ()
#3  0x00007fcd068c2040 in ?? ()
#4  0x000055f2f6109c48 in ?? ()
#5  0x0000000000000000 in ?? ()

build with gcc -Wall -O0 -g

How can I debug this, are there more methods?

gacopu
  • 594
  • 3
  • 21

1 Answers1

1

gdb bt

Surely that is not the command you actually executed.

Most likely you did something like this:

gdb /path/to/core
(gdb) bt

Don't do that. Do this instead:

gdb /path/to/a.out /path/to/core
(gdb) bt

If you already did invoke GDB correctly, other likely reasons why bt did not work:

  1. You are analyzing the core on a different machine from the one on which it was produced. See this answer.
  2. You rebuilt a.out with different flags. Use the exact binary that crashed.
  3. You have updated libc after the core was produced. Restore it to the version that was current as of when the core was produced.

P.S. This command

addr2line -e a.out 00007fcd16e5853a

makes no sense: the error message told you that the address 00007fcd16e5853a is in libc-2.24.so. The a.out has nothing to do with that address.

The command you want to use is:

addr2line -fe /path/to/libc-2.24.so 195000

P.P.S.

segfault at 0 ip 00007fcd16e5853a ...

This means: NULL pointer dereference inside libc. The most probable cause: not checking for error return, e.g. something like:

FILE *fp = fopen("/some/file", "r");
fscanf(fp, buffer, sizeof(buffer));  // Oops: didn't check for NULL.
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Thanks, the gdb part is correct, I just simplified that. I'll check the libc part NULL check – gacopu Nov 25 '18 at 02:28