This question already has answers here:
gdb can not open shared object file
(2 answers)
Closed 3 years ago.
Im trying to debug my c++ program. I can run it fine normally but when I attempt to run the exe through gdb it suddenly cant find my so files. The directory is in my path and when I try "show environment" in gdb the path still shows the directory but it cant find the so files.
I ran
gdb --args ${EXE} ${ARGS}
and I get back
error while loading shared libraries: libX.so: cannot open shared object file: No such file or directory.
You should check the shared library search path using the command:
(gdb) set solib-search-path.
To check which libraries are already loaded:
(gdb) info sharedlibrary.
To manually load a shared library if it is not loaded: (gdb) sharedlibrary libTest.
The following command may also be useful to check which files have their symbols loaded already: (gdb) info sources.
Related
I have an embedded ARM application which is bundled with all the so-libraries stripped, including the libpthread.so. Sometimes the application gets stuck in some part of code and I want to be able to attach to it with gdb and see what's going on. The problem is that gdb refuses to load the needed threading support library, with the following messages:
Trying host libthread_db library: /home/me/debug_libs/libthread_db.so.1.
td_ta_new failed: application not linked with libthread
thread_db_load_search returning 0
warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.
Because of this I cannot debug the application, e.g. I cannot see current call stacks for all threads.
After some investigation I suspect that the td_ta_new failing with the application not linked with libthread is caused by the stripped version of libpthread, which lacks the nptl_version symbol. Is there any way to bypass the error?
The gdb is compiled for ARM and being run on the device itself. I have unstripped versions of the libraries, but the application is already running with the stripped libraries.
Is there any way to bypass the error?
A few ways that come to mind:
Use add-symbol-file to override the stripped libpthread.so.0 with un-stripped one:
(gdb) info shared libpthread.so
# shows the path and memory address where stripped libpthread.so.0 is loaded
(gdb) add-symbol-file /path/to/unstripped/libpthread.so.0 $address
# should override with new symbols, and attempt to re-load libthread_db.so.1
Run gdb -ex 'set sysroot /path/to/unstripped' ... where /path/to/unstripped is the path that mirrors installed tree (that is, if you are using /lib/libpthread.so.0, there should be /path/to/unstripped/lib/libpthread.so.0.
I have not tested this, but I believe it should work.
You could comment out the version check in GDB and rebuild it.
I am running GDB on a Linux process and I find this whenever a breakpoint is hit.
GDB issue BFD: reopening /tmp/ .. : No such file or directory
I see a bug opened but not sure if someone knows solution to this.
https://sourceware.org/bugzilla/show_bug.cgi?id=14202
The problem is that gdb lazily loads some sections, but you have deleted the shared library.
One fix is not to delete the shared library while gdb is using it.
Another fix is to modify gdb not to lazily load sections. If you go this route, the lazy loading is all done in dwarf2read.c.
Perhaps, i misunderstand something, but i can't make Gdb to read debug libraries.
what i do from command line is:
gdb
file problem_exec
b main
r
GDB stops at:
(gdb) r
Starting program: /Users/.../problem_exec
Breakpoint 1, main (argc=<error reading variable: Could not find the frame base for "main(int, char**)".>, argv=<error reading variable: Could not find the frame base for "main(int, char**)".>)
No shared libraries:
(gdb) info shared
No shared libraries loaded at this time.
The last command gives: "No shared libraries loaded at this time."
My .gdbinit looks like:
# file .gdbinit
set stop-on-solib-events 1
# stop gdb from stepping over functions and output diagnostics
set step-mode on
set breakpoint pending on
set env DYLD_LIBRARY_PATH path1:path2:path3
#automatically load shared libraries (on/off):
set auto-solib-add on
I am sure that an executable is linked against debug version of the shared libraries (in total there are some 30 libraries, but the one I am interested in is definitely compiled in a debug mode). I checked it with otool -L problem_exec
If I run program, it goes until a run-time error in the library I want to debug, but i can not step in.
Am I missing something?
p.s. I run self-compiled version of Gdb on os-x.
UPDATE: it could be related to this problem.
set stop-on-solib-events 1
With that setting, GDB should stop before any shared libraries are loaded.
When you do this:
file problem_exec
b main
r
... where is GDB stopped?
info shared
If GDB is stopped at main, then shared libraries should be loaded. But if it is stopped in the dynamic loader (as I expect it is), then they should not be loaded yet.
I'm attempting to get the nacl-gdb working with one of the example applications provided with the nacl_sdk. In particular, I'm trying to get it working with the sample hello_tutorial application in the getting_started/part1 folder (the stub code from this tutorial: https://developers.google.com/native-client/dev/devguide/tutorial/tutorial-part1).
I've tried following the instructions here: https://developers.google.com/native-client/dev/devguide/devcycle/debugging#debugging-with-nacl-gdb
But whenever I connect to the target, gdb prints out the following:
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I can then continue and the application runs, but it it's very helpful without the debugging symbols. Anybody know why this might not be working properly?
I performed the following steps:
Modified the Makefile to build hello_tutorial.pexe without finalizing it, and added the -g flag when compiling, and re-ran make.
Ran pnacl-translate to create the .nexe files from the un-finalized .pexe.
../../toolchain/linux_pnacl/bin/pnacl-translate --allow-llvm-bitcode-input hello_tutorial.pexe -arch x86-64 -o hello_tutorial_x86_64.nexe
Modified the hello_tutorial.nmf to point to the nexe files instead of the pexe file.
Modified index.html to point to "application/x-nacl", instead of "application/x-pnacl"
Started Chrome with the following command:
/opt/google/chrome/chrome --enable-nacl --enable-nacl-debug --no-sandbox --disable-hang-monitor localhost:5103
Start up the debugger from the part1 folder with the following command:
../../toolchain/linux_x86_newlib/bin/x86_64-nacl-gdb
Ran the following commands from within gdb. (Note that it shows "no debugging symbols found" when reading from the nacl_irt_x86_64.nexe - is that a problem?)
(gdb) nacl-irt hello_tutorial_x86_64.nexe
Reading symbols from /home/bender/dev/nacl_sdk/pepper_33/getting_started/part1/hello_tutorial_x86_64.nexe...done.
(gdb) nacl-irt /opt/google/chrome/nacl_irt_x86_64.nexe
Reading symbols from /opt/google/chrome/nacl_irt_x86_64.nexe...(no debugging symbols found)...done.
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I'm running on Linux:
Linux bender-VirtualBox 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Looks like this is working okay if I use pepper_canary instead of pepper_33. Found some info at this link: https://code.google.com/p/nativeclient/issues/detail?id=3739
I'm trying to debug a CUDA program, but when I'm launching gdb like so:
$ gdb -i=mi <program name>
$ r <program arguments>
I'm getting:
/home/wvxvw/Projects/cuda/exercise-1-udacity/cs344/HW2/hw:
error while loading shared libraries: libcudart.so.5.0:
cannot open shared object file: No such file or directory
Process gdb-inferior killed
(formatted for readability)
(I'm running gdb using M-xgdb) If that matters, then CUDA libraries are in the .bashrc
export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
error while loading shared libraries: libcudart.so.5.0
This error has nothing to do with GDB: your executable, when run from inside GDB, can't find the library it needs.
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
GDB runs your program in a new $SHELL, so that should have worked. I wonder if there is some interaction with emacs.
In any case, this:
(gdb) set env LD_LIBRARY_PATH /usr/local/cuda/lib64
(gdb) run
should fix this problem.
Update:
as I've mentioned it before, ld path is set properly
No, it isn't. If it was, you wouldn't have the problem.
Now, I don't know why it isn't set properly. If you really want to find out, start by running GDB outside emacs (to exclude possible emacs interactions).
If the problem is still present, gdb show env, shell env, adding echo "Here" to your ~/.basrc, etc. should help you find where things are not working as you expect them.
I've had this problem as well. One way to look at it is that even if the LD_LIBRARY_PATH variable is correct when you enter show env into gdb, it may not be correct when you actually execute the program because gdb executes $SHELL -c <program> to run the program. Try this as a test, run $SHELL from the command line and then echo $LD_LIBRARY_PATH. Is it correct? If not, then you probably need to add it to your rc (.tcshrc in my case).
I had a similar problem when trying to run gdb on windows 7. I use MobaXterm to access a Linux toolbox. I installed gdb separately from http://www.gnu.org/software/gdb/ . I got it to work by making sure gdb could find the correct .dll files as mentioned by Employed Russian. If you have MobaXterm installed the .dll files should appear in your home directory in MobaXterm/slash/bin.
gdb however did not recognize the LD_LIBRARY_PATH variable. For me, it worked when I used the PATH variable instead:
(gdb) set env PATH C:\Users\Joshua\Documents\MobaXterm\slash\bin
(gdb) run
I would think using PATH instead of LD_LIBRARY_PATH might work for you provided you put the correct path to your library.
gdb is looking for a library, so why are you concerned with the include path? You may want to try to set the gdb option "solib-search-path" to point to the location of the libcudart.so.5.0 library.