I have met a freaky problem during my internship. My work is to code with VTK in C++ and I worked on OSX 10.8.3.
When I want to debug my program, I ran the gdb and use instruction "file" to load my program, then I used "list" to show the source code to make a breakpoint by line number. Here goes the problem: this freaky gdb showed the source code of a VTK header file which I even hadn't included in my source code!
My program's name is read
I have tried to use gdb read then break read:15 to set a breakpoint but the gdb displayed "no source file named read" that is ridiculous!
I have noticed that gdb works well in my ubuntu 12.04 and when I use file read in linux's gdb, it just displayed
Reading symbols from /Users/apple/Dev/VTKRead/bin/bin/read...done.
but in my OSX 10.8.3's freaky gdb it displayed
Reading symbols for shared libraries ......... done
Reading symbols from /Users/apple/Dev/VTKRead/bin/bin/read...done.
I think that is the reason and I tried to change compiler to solve problem by install gcc4.8 in macport but cmake seems only accept the apple's gcc.
but the gdb displayed "no source file named read" that is ridiculous!
That is not rigiculous at all: you very likely don't have a source file called read. What you do have is probably called read.cc, or read.cpp, so try break read.cc:15.
That is my mistake: I didn't set the build tag to "debug" in ccmake, so the compiler didn't write the information into the file.
Related
I'm currently running a file manager program that abruptly crashed with a segmentation fault and dumped a core file. So I used gdb to debug the core file as:
gdb /path/to/executable /path/to/core
The program which I was running is written in C++. When I ran GDB and tried to print the source lines using "list", I got the following error:
(gdb) bt
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
#1 0x00000000005ab2e8 in
MyGenericDirCtrl::OnFileWatcherEvent(wxFileSystemWatcherEvent&) ()
(gdb) f 0
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
(gdb) l
1 /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory." I do not hit this issue with some other programs that I've debugged using gdb.
The operating system used is Ubuntu 16.04 running on Oracle virtual box. I think may be the gdb symbols were not loaded. I'm not sure why since I compiled the program using the "-g" option. I really need to know the source lines where the code crashes via gdb.
Any suggestions?
EDIT: changes after suggestions from Employed Russian
I was compiling my main using "-g" option and linking it to "existing" object files which were obviously not compiled using "-g" so when the core dumped, I could not see the source for these files. So I went ahead and recompiled those files with "-g" option and reproduced the core dump. It's able to show me the source lines now.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory."
Because you really don't have that file on your system.
I think may be the gdb symbols were not loaded
GDB did load debug symbols for glib, but not for your main executable.
I'm not sure why since I compiled the program using the "-g" option.
Since we don't have your compile and link lines, we can't tell exactly what's wrong, but some of the common issues are:
You have a "stray" -s or -Wl,-s on your link line (this strips debug info from the resulting binary).
You have -g when compiling your main.c, but not when compiling the source in which MyFSEventManager::AddEvent() is defined
P.S.
(gdb) bt
This doesn't seem to be the complete output from bt command. Always try to paste complete outputs as it makes helping easier :)
If I start gdb -tui or gdbtui with an -g flag compiled file, then set b main and press r I get the hint dl-debug.c:74 no such file or directory and the output while stepping through the source window will be written to the source window at the bottom, which also messes up this window so that is not really readable. I've already looked at askubuntu.com and Sourceware Bugzilla – Bug List and at this site but found no solution.
I also tried out sudo apt-get install ddd on another machine to go to the trouble out of the way, but then I only get authentication failure, which I also already asked without response on ask ubuntu.
Any help or hint is appreciated.
dl-debug.c:74 no such file or directory
This message means that you've tried to step into GLIBC (more precisely the dynamic loader) source, which you didn't install.
Solution: don't try to step into it, or install GLIBC source and make GDB find it (help directory).
Is nacl-gdb only for *.nexe and not *.pexe files? im following the guide at https://developers.google.com/native-client/devguide/devcycle/debugging#gdb
./$NACL_SDK_ROOT/toolchain/mac_x86_newlib/bin/x86_64-nacl-gdb
...
This GDB was configured as "--host=i386-apple-darwin10.8.0 --target=x86_64-nacl".
...
(gdb) nacl-manifest code.nmf
(gdb) nacl-irt pnacl/Release/code.pexe
`pnacl/Release/code.pexe': can't read symbols: File format not recognized.
The .pexe is not the final executable, and nacl-gdb does not understand its format. It's a target-independent "intermediate format" file that has to be translated by the browser to a native module before it can be executed and/or debugged.
You can debug .nexes produced by the PNaCl toolchain, by compiling all the way to a .nexe with debug information and then debugging that. In other words, just as you debug a .nexe produced by the gcc toolchains.
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.
In c or c++ While debugging a core dump,i.e., if we are left with a coredump file and try to debug using that core file is there a way we can see the last few lines of code before the dump occured.the stack trace only shows the function call.
for eg:during debugging a running process in dbx or gdb list command
list Display lines of a source file
will give the part of the code currently under execution.in the same way do we have the option while looking into a core dump?
i am working on solaris mdb
The list command in gdb should provide details of source code line numbers and the corresponding source listing from a core file if:
The executable was compiled with debug symbols enabled (eg. -g in gcc and g++)
A non-stripped version of the executable is available (ie. has not had the debug information removed by running strip)
The debugger is able to find the relevant source files
The debugger should still be able to provide file and line numbers even if it is unable to find the source files as the line number information forms a part of the debug symbols. This information should be available through the bt (backtrace) command, as well as the info symbol command.
Note that even if the core file was generated from a stripped executable, as long as you have access to a non-stripped version you can load that in gdb as well as specifying the core file.
Take a look at chapter 13 and 15 of the gdb manual to assist in giving gdb access to your source files.
If you compiled with -g option you can display source lines. In dbx you can use use command to set dbx source directories.
You can use list (l) command to display source lines.
See help command to learn how to use dbx and gdb commands.
If you have set your source path properly using use command in dbx or started it with -I option, then there's hardly any difference between debugging a core dump and a normal process when it comes to reading source lines.