Issue
I am debugging a C application running with a dynamically linked shared library. The program runs well on Ubuntu 14.04 64 bit. But it generates segmentation fault on Ubuntu 16.04 when Linux terminates the shared objects upon exiting the application.
Inside gdb, I set a breakpoint right before the segmentation fault happens. Then I use info source to check the source file information:
Thread 1 "test" hit Breakpoint 3, _dl_fini () at dl-fini.c:201
(gdb) info source
Current source file is dl-fini.c
Compilation directory is /build/glibc-bfm8X4/glibc-2.23/elf
Located in /build/glibc-bfm8X4/glibc-2.23/elf/dl-fini.c
Source language is c.
Producer is GNU C11 5.4.0 20160609 -mno-mmx -mtune=generic -march=x86-64 -g -O2 -O3 -std=gnu11 -fgnu89-inline -fno-stack-protector -fmerge-all-constants -frounding-math -fPIC -ftls-model=initial-exec.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
I am not able to find the indicated Compilation directory and the location of the source file.
Directory /build/glibc-bfm8X4/glibc-2.23/elf doesn't exist. Anyone has any idea of this situation?
Solution
That's the directory on the machine where the glibc was compiled. It doesn't exist on our machines.
Install the -dbg versions of the involved packages (using sudo apt-get install) - to get the debug symbols installed. Get the source code of the libraries (by using apt-get source) - to get the actual source files downloaded into the current directory.
For glibc it's sudo apt-get install libc6-dbg and apt-get source libc6
Useful commands:
- list all packages:
dpkg -l(can thengrepin the list for the specific package name) - list files in a package:
dpkg -L <package name> - search for a package to which the file belongs to:
dpkg -S <file path>
Use the directory <path to source dir> declarations in ~/.gdbinit to point gdb to the right directories with the source code.
Also, try valgrind and rr utilities.
Answered By - Velkan