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.
Related
I'm using gcc 4.9.2 & gdb 7.2 in Solaris 10 on sparc. The following was tested after compiling/linking with -g, -ggdb, and -ggdb3.
When I attach to a process:
~ gdb
/snip/
(gdb) attach pid_goes_here
... it is not loading symbolic information. I started with netbeans which starts gdb without specifying the executable name until after the attach occurs, but I've eliminated netbeans as the cause.
I can force it to load the symbol table under netbeans if I do one of the following:
Attach to the process, then in the debugger console do one of the following:
(gdb) detach
(gdb) file /path/to/file
(gdb) attach the_pid_goes_here
or
(gdb) file /path/to/file
(gdb) sharedlibrary .
I want to know if there's a more automatic way I can force this behavior. So far googling has turned up zilch.
I want to know if there's a more automatic way I can force this behavior.
It looks like a bug.
Are you sure that the main executable symbols are loaded? This bug says that attach pid without giving the binary doesn't work on Solaris at all.
In any case, it's supposed to work automatically, so your best bet to make it work better is probably to file a bug, and wait for it to be fixed (or send a patch to fix it yourself :-)
I am trying to put the gdb to run with eclipse cdt on ubuntu to start debugging some simple programs. So I did the steps I reckon as necessary to get it running:
1. Create an executable project
2. Compile
3. Run
4. Create the file .gdbinit and place it on the main project folder
5. Set some of the debugger configuration:
5. I also tried to find a .gdbinit file that would look some like this:
set schedule-multiple
dir ~/gcc_build/4.7.2/build/gcc
dir ~/gcc_build/4.7.2/gcc
dir ~/gcc_build/4.7.2/gcc/cp
dir ~/gcc_build/4.7.2/gcc/lto
source ~/gcc_build/4.7.2/build/gcc/gdbinit.in
But I didn't find anything similar in my computer, even after doing a:
# find / -name .gdbinit
So, my file .gdbinit end up with the simple content - yes only that:
set new-console on
Then I clicked on Apply and Debug:
The gdb starts working nicely as expected. I press the button "step over / F6" and the debugger goes jumping through the code step by step. Until the point it reaches the command rand() and the gdb hangs with the message:
Can't find a source file at "/build/buildd/eglibc-2.19/stdlib/rand.c"
Locate the file or edit the source lookup path to include its location.
Thus I also tried unsuccessfully to find the rand.c to update this path to include its location:
# find / -name rand.c
# find / -name stdlib
After the error message from GDB complaining that rand.c is missing, then I tried to keep stepping... since then the stepping mode is disable when I restart the debug:
Is this problem happening because some setting for my file .gdbinit is missing? Or some how GDB is not able to find the rand.c from stdlib from c99? When I compile and run the program it runs nicely. Only when I try to launch the debugger is when GDB crashes.
Update: I got the missing rand.c problem after running the commands:
# apt-get install libc6-dbg
# apt-get source libc6
But now a different error appears:
Can't find a source file at "/build/buildd/eglibc-2.19/csu/libc-start.c"
Locate the file or edit the source lookup path to include its location.
Should I also install that library for gdb?
All suggestions are highly appreciated.
From what I saw on your description... looking to the 4th and 5th image you posted, you did right all the required steps.
However, it seems to me that your GDB is attached to several projects. That means that unless you really need that, I would strongly advise you to select all project that you are not currently debugging and delete them from the debugger mode. So, my suggestion is that after you have done all the steps you did so far, then go on:
Debug Configurations > C/C++ Applications: (drop down it)
... then click on each project you are not compiling, with right button from the mouse select "delete" - but don't worry, it will not delete your project, but only the attachment of that project to your debugger mode.
Then restart the eclipse. When you again try to run in the debugger mode, everything will run much smoother than before.
Step1:
Go to https://www.gnu.org/software/libc/ to download glibc.
Step2:
unzip it locally and whenever the eclipse prompts "Can't find ... xxx.c", just load the file into eclipse. It will work.
I am trying to debug a Go-program using gdb and setting breakpoints works normally in all packages, except for one. In my src-folder I have 3 subfolders that each contain packages:
crawler/
crawler.go
model/
page.go
urlutils/
urlutils.go
I cannot set a breakpoint in page.go on any line as it gives me the following error:
(gdb) break model/page.go:14
No source file named model/page.go.
Make breakpoint pending on future shared library load? (y or [n])
I do not understand why this is happening with only this one package. "model/page" is also an import in the file that contains the main function and is used when the program runs, so it must be in the executable. Does anyone have an idea?
I found a solution:
I needed to add a flag to my go build command:
go build -gcflags "-N -l" launch.go
This disables the code optimization performed by the go compiler which lead to my breakpoint working. The paths were correct and also the absolute path didn't work.
Nevertheless, thank you tomwilde for pointing me into a direction.
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.
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.