Afternoon,everbody.
I have an application 'test' compiled by main.c . A dynamic liabrary 'libtest.so' which is compiled by test.cpp with '-g'. In main.c I invoke the 'libtest.so' with 'dlopen' . And now I want to set a breakpoint in test.cpp ,but the gdb never hit it. I do as follow:
gdb ./test -d /home/lcl/test
break test.cpp:35
run
can anybody give me some tips ,thanks!
You should first verify that dlopen is actually succeeding (it's likely that it's not).
To do so:
set a breakpoint in main.c after dlopen.
confirm that returned handle is not NULL
At that point, GDB should have loaded symbols for libtest.so, and libtest.so should show up in info shared GDB output.
If everything looks good, info break should show an active breakpoint in test.cpp:35 at some address. If that breakpoint is never hit, it's likely that you never actually exercise that line of code.
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 :)
Is there any gcc option I can set that will give me the line number of the segmentation fault?
I know I can:
Debug line by line
Put printfs in the code to narrow down.
Edits:
bt / where on gdb give No stack.
Helpful suggestion
I don't know of a gcc option, but you should be able to run the application with gdb and then when it crashes, type where to take a look at the stack when it exited, which should get you close.
$ gdb blah
(gdb) run
(gdb) where
Edit for completeness:
You should also make sure to build the application with debug flags on using the -g gcc option to include line numbers in the executable.
Another option is to use the bt (backtrace) command.
Here's a complete shell/gdb session
$ gcc -ggdb myproj.c
$ gdb a.out
gdb> run --some-option=foo --other-option=bar
(gdb will say your program hit a segfault)
gdb> bt
(gdb prints a stack trace)
gdb> q
[are you sure, your program is still running]? y
$ emacs myproj.c # heh, I know what the error is now...
Happy hacking :-)
You can get gcc to print you a stacktrace when your program gets a SEGV signal, similar to how Java and other friendlier languages handle null pointer exceptions. See my answer here for more details:
how to generate a stacktace when my C++ app crashes ( using gcc compiler )
The nice thing about this is you can just leave it in your code; you don't need to run things through gdb to get the nice debug output.
If you compile with -g and follow the instructions there, you can use a command-line tool like addr2line to get file/line information from the output.
Run it under valgrind.
you also need to build with debug flags on -g
You can also open the core dump with gdb (you need -g though).
If all the preceding suggestions to compile with debugging (-g) and run under a debugger (gdb, run, bt) are not working for you, then:
Elementary: Maybe you're not running under the debugger, you're just trying to analyze the postmortem core dump. (If you start a debug session, but don't run the program, or if it exits, then when you ask for a backtrace, gdb will say "No stack" -- because there's no running program at all. Don't forget to type "run".) If it segfaulted, don't forget to add the third argument (core) when you run gdb, otherwise you start in the same state, not attached to any particular process or memory image.
Difficult: If your program is/was really running but your gdb is saying "No stack" perhaps your stack pointer is badly smashed. In which case, you may be a buffer overflow problem somewhere, severe enough to mash your runtime state entirely. GCC 4.1 supports the ProPolice "Stack Smashing Protector" that is enabled with -fstack-protector-all. It can be added to GCC 3.x with a patch.
There is no method for GCC to provide this information, you'll have to rely on an external program like GDB.
GDB can give you the line where a crash occurred with the "bt" (short for "backtrace") command after the program has seg faulted. This will give you not only the line of the crash, but the whole stack of the program (so you can see what called the function where the crash happened).
The No stack problem seems to happen when the program exit successfully.
For the record, I had this problem because I had forgotten a return in my code, which made my program exit with failure code.
I created a Hello World example in C++ and tried to debug it with lldb from the terminal on Mac OSX.
> lldb a.out
Current executable set to 'a.out' (x86_64).
I can set breakpoints on names (eg. 'main'), but not on line numbers. If I try
breakpoint set --file test.c --line 5
or
b test.c:5
I get
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
The file 'test.c' is located in the current folder. What goes wrong?
Acording to Dwarf Debugging Information Format, the line number, file location information are stored in the Dwarf format. Such information is what GDB used to set line number as a breakpoint.
Usually, the Dwarf format information is generated by compiler, such as GCC with the -g options. Please try with -g options to see whether it works.
Meanwhile, there also some other debug helpful options in GCC which might be more helpful to you, such as -g3, compiler will generate more detail information for debug, such as macros.
Does anybody know how so use gdb in emacs?
I am using this command to create my program
/home/cdim/Local/gcc-4.9.2/bin/gfortran -ffree-form -g ./utests/test_gdb.f -o test_gdb
I am going to Emacs Tools then Debugger (GDB). I then click on the run button and nothing happens.
What does test_gdb do if you run it outside of gdb? If it sends no output to the screen then this (i.e., no output) is exactly what you will see when you run it inside of gdb - if you have set no breakpoints. Did you set a breakpoint? And how much nothing happens when you click run? Even if test_gdb produces no output, if all is well you should still see gdb display a notification like
[Inferior 1 (process 12345) exited normally]
Consider test.f:
Program p
Integer :: i = 1
Print *, i
End
I would compile this with gfortran -ffree-form -g -ggdb test.f -o test_gdb.
(From https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options:
-ggdb
Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.
)
Then, as you said, go to Tools -> Debugger (GDB) (or issue M-x gdb) in emacs and make sure the gdb invocation is using the full path to the executable, e.g. Run gdb (like this): gdb -i=mi /foo/bar/test_gdb. Hit return in that minibuffer.
Now, set a breakpoint in the new *gud-test_gdb* buffer:
(gdb) break p
Breakpoint 1 at 0x4007e1: file test.f, line 3.
Then go to menu entry Gud -> Run.
Esc+x then entern gdb ... and input your application file. it will start gdb in emacs
I solved problem by moving to Trisquel 7.0. Might have been a setup problem.
I have an executable that dynamically loads a shared object library, let say foo.so. I do not build foo.so and it is given to me as a library to use in my code. foo.cpp compiles to give foo.so. I do not have access to foo.cpp but have foo.so. I want to set a breakpoint when my executable calls a function inside this shared library foo.so (that is when function inside foo.cpp is called). Is their a way in gdb to do so?
I have tried
gdb funcname
but it does not seem to work. Any pointers how to break gdb at that point?
Is their a way in gdb to do so?
Yes.
I have tried gdb funcname
That wouldn't work. You need to run gdb exename, then break funcname at the (gdb) prompt.
At that point, GDB will likely inform you that funcname does not yet exist (since you haven't yet dynamically loaded foo.so), and will ask you whether you want to create a deferred breakpoint. You should answer yes, and GDB will retry setting this breakpoint every time a new shared library is loaded. Eventually this will succeed, and you should get the breakpoint set (automatically and silently), and when you call the funcname later, that breakpoint will fire and GDB will stop (which is exactly what you want).