gdb newbie here, so I hope I haven't overlooked something glaringly obvious… (and if I did, maybe a kind soul could point it out anyway? ;)
I'm debugging a GCC C++ application under OS X Lion. As it's quite heavy on STL, I'd really like to use a GDB version with python support (i.e. >=v7) for pretty printing of containers. My application is split up into a backend library (.dylib) that does all the heavy lifting, and a very simple frontend application. All of the sources and binaries are below a common source path, and everything has been compiled with debugging symbols (I tried both -g and -ggdb).
Using the GDB version in XCode (which identifies as "GNU gdb 6.3.50-20050815 (Apple version gdb-1820)"), displaying the source lines of frames in a backtrace works as expected out of the box, no matter whether the respective call happens in the frontend app or the backend library:
(gdb) f 12
#12 0x000000010002ddc5 in FL3D::Resource::createMesh_ (this=0x7fff5fbff7c8, fl3d=#0x7fff5fbff1f8, id=) at /Development/workspace/fl3d/libfl3d/resource.cpp:234
234 std::vector& t = textureIndices_.at(i);
(gdb)
So far so good. GDB 7.5 and 7.4.1, on the other hand, refuse to give me any source lines from the library:
(gdb) f 12
#12 0x000000010002ddc5 in FL3D::Resource::createMesh_(FL3D::FL3DParser&, std::string) ()
from /Development/workspace/fl3d/libfl3d/build/libfl3d.dylib
(gdb)
I'm really confused by the different responses given – gdb6 prints the correct path to the source file and the correct line, while gdb7 gets the function prototype right (supposedly read from the debugging symbols of the .dylib?), but doesn't seem to know anything about the source. Interestingly, though, it DOES show the corresponding source line for calls in the frontend's main() function!
I've already tried manually setting the path to the library's source files with "dir libfl3d", but that doesn't change anything. I also notice that gdb6 says "Reading symbols for shared libraries" a few times when I run the application and gdb7 doesn't – but the symbols don't seem to be the problem, as they seem to be resolved correctly by both versions?
I'm at my wit's end here. Any pointers?
The Apple gdb is displaying the debug information because it knows how to find & parse DWARF on this platform. The gdb version 7 that you're showing is a gdb that doesn't know how to find the DWARF debug information on a Mac OS X system -- that output that you're showing above is what no-debug-info looks like. My guess is that the FSF gdb version 7 support for Mac OS X has not seen a lot of attention, I would be hesitant to recommend using it on this platform.
As bames53 notes, you're far better off using LLDB on Mac OS X at this point. It is the debugger that all of the support work is going in to and Objective-C / C++ container support is rapidly being added to LLDB but not gdb. The gdb provided by Apple is on an end-of-life path and all users will be switched over to LLDB in the future.
Give lldb a try. It's a little different but it's quite good. There is a cheat sheet that a lot of people find useful in the beginning, it shows gdb and lldb command equivalences. http://lldb.llvm.org/lldb-gdb.html
Related
I'm working on a relatively old Centos system where I am restricted in the packages I can install. I needed a newer version of gdb, so I built that successfully from source in my home dir. This gdb steps through my code fine, but I am looking for trouble that is manifesting in the C++ allocator (mt_allocator.cc) and this new version of gdb can't step through that code. I can break successfully on a function there:
break '__gnu_cxx::__pool<true>::_M_initialize()'
but when that breakpoint hits and I try to step through the code, gdb tells me:
Single stepping until exit from function _ZN9__gnu_cxx6__poolILb1EE13_M_initializeEv,
which has no line number information.
I tried using the dir command within gdb to add the path to where mt_allocator.cc is, but that had no effect.
What do I need to tell gdb so it can find those files?
Ah, found it. The Centos package manager put the debug files for the STL code at /usr/lib/debug. So:
set debug-file-directory /usr/lib/debug
within gdb gets it done.
I installed XCode 5.1 with clang
I installed gcc 4.8 via homebrew
Installed gdb 7.7.1 via homebrew
Using OSX 10.9.3
I compile my c++ source in eclipse kepler with a Makefile using g++-4.8 and try to debug it but when reaching a breakpoint I can't see any variables just like in this question: GDB says "no symbol table," but nm shows file has debug symbols
I followed the suggestions of #Tom Tromey in the suggestions section of that question to use
set complaints 10000
in gdb and then load the file. This revealed lots of errors during loading. First I saw lots of these:
unhandled stab for dwarf OSO file...unhandled stab for dwarf OSO file...
then lots of these:
During symbol reading, location expression too complex.
During symbol reading, Member function "~clone_impl" (offset 414143) is virtual but the vtable offset is not specified.
and then a whole lot more of these:
During symbol reading, unexpected overlap between:
(A) section `__TEXT.__textcoal_nt' from `<snip>/sourcefilename.o' [0x228, 0x28c)
(B) section `__TEXT.__textcoal_nt' from `<snip>/differentsourcefilename.o' [0x268, 0x2cc).
Will ignore section B.
There are lots of errors where one section is being ignored in favor of another.
I used to think gdb was the culprit but I have found today that if I use llvm-g++ instead, then gdb works as expected. I was overjoyed at finding I could actually debug without using cout statements.
Another similar question: How do I get a homebrewed version of GDB working on Mac OS X?
I would like to fix the problem with g++-4.8 and need help.
Most of the answers I found related to outdated versions of gdb but 7.7.1 is pretty recent and should work based on what others suggested on SO.
Issue
I am having difficulty debugging inside of my application's timerEvent functions. While the application is able to run, if I set a breakpoint inside of even something as simple as the following, I receive an error message stating: "The gdb process crashed."
void MyClass::timerEvent (QTimerEvent *e) {
std::cout << "TIMER!";
}
I have included a debugger log here via pastebin.
Attempts
To try and fix this, I tried upgrading gdb iteratively with each version of QT-creator to no avail.
I am using:
Linux ubuntu-x86 2.6.32-42-generic #95-Ubuntu 10.04LTS SMP i686 GNU/Linux
QT creator (versions 2.4 through 2.5.2)
gdb (7.1 through 7.5) targeting "x86-linux-generic-elf-32bit"
pythongdb (7.2)
Questions
My questions are twofold, namely:
What is causing gdb to crash?
and
What can I do to make it work?
Failing that, I wonder: Where else should I look for more details of the crash?
Any and all help is greatly appreciated.
Make sure your QT libraries are up to date. Even though a new QT-creator will install via the handy-dandy .bin file they provide, it was built using the newer QT libraries, and expects them to be in place. If they are not, well...
Additionally, if you are not installing gdb into one of the standard directories where QT-creator can find it, make sure you add it manually to your toolchains via tools->options->build and run->toolchains.
I use pstack to analyze core dump files in Solaris
How else can I analyze the core dump from solaris?
What commands can be used to do this?
What other information will be available from the dump?
You can use Solaris modular debugger,mdb, or dbx. mdb comes with SUNWmdb (or SUNWmdb x for the 64 bits version) package.
A core file is the image of your running process at the time it crashed.
Depending on whether your application was compiled with debug flags or not,you will be able to view an image of the stack, hence to know which function caused the core, to get the value of the parameters that were passed to that function, the value of the variables, the allocated memory zones ...
On recent solaris versions, you can configure what the core file will contain with the coreadm command ; for instance, you can have the mapped memory segments the process were attached to.
Refer to MDB documentation and dbx documentation. The GDB quick reference card is also helpful once you know the basics of GDB.
I guess any answer to this question should start with a simple recipe:
For dbx, the recipe is:
% dbx a.out core
(dbx) where
(dbx) threads
(dbx) thread t#3
(dbx) where
If the core dump is from a program you wrote or built, then use whichever debugger you would normally use to debug the running application. They should all be able to load core files. If you're not picky about debuggers, and you're using Solaris, I would recommend dbx. It will help to get the latest FCS version of Sun Studio with patches, or else the latest Express version of Sun Studio. It's also very helpful if you can load the core file into the debugger on the same system where the core file was created. If the code in the libraries is different from when the core file was created, then stack trace won't be useful when it goes through libraries. Debuggers also use OS helper libraries for understanding the libthread and runtime linker data structures, so IF you need to load the core file on a different machine, you'll want to make sure the helper libraries installed on the OS match the system data structures in the OS. You can find out everything you never wanted to know about these system libraries in a white paper that was written a few years ago.
http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content.html
The pflags command is also useful for determining the state each thread was in when it core dumped. In this way you can often pinpoint the problem.
I would suggest trying gdb first as it's easier to learn basic tasks than the native Solaris debuggers in my opinion.
GDB can be used.
It can give the call that was attempted prior to the dump.
http://sourceware.org/gdb/
http://en.wikipedia.org/wiki/GDB
Having the source is great and if you can reproduce the errors even better as you can use this to debug it.
Worked great for me in the past.
Attach to the process image using the dbx debugger:
dbx [executable_file_name] [coredump_file_name]
It is important that there were no changes to the executable since the core was dumped (i.e. it wasn't rebuilt).
You can see the stack trace to see where the program crashed with dbx command "where".
You can move up and down the stack with command "up" and "down", or jump to the exact stack frame with "frame [number]", with the numbers seen in the output of "where".
You can print the value of variables or expressions with "print [expr]" command.
Have fun.
I found dbx on my solaris x86 box at
/opt/SUNWspro/bin/dbx
Cheers!
We're using the Eclipse CDT 5 C++ IDE on Windows to develop a C++ application on a remote AIX host.
Eclipse CDT has the ability to perform remote debugging using gdbserver. Unfortunately, gdbserver is not supported on AIX.
Is anyone familiar with a way to debug remotely using Eclipse CDT without gdbserver? Perhaps using an SSH shell connection to gdb?
finally I got gdb run remotly anyhow now. At the Bug-symbol on the taskbar I took Debug Configurations - GDB Hardware Debugging.
In Main C/C++ Applications I set the full path on the Samba share of the executable (X:\abin\vlmi9506). I also set a linked folder on X:\abin in the project. Then I modified my batch-script in GDB Setup. It's not directly calling gdb in the plink-session but a unix-shell-script, which opens gdb. By this I have the possibility to set some unix environment-variables for the program before doing debug. The call in my batch:
plink.exe prevoax1 -l suttera -pw XXXXX -i /proj/user/dev/suttera/vl/9506/test/vlmi9506ddd.run 20155 dev o m
In the unix script I started gdb with the command line params from eclipse, that I found in my former tryals. The call in the shell command looks like this:
gdb -nw -i mi -cd=$LVarPathExec $LVarPathExec/vlmi9506
Then IBM just gives gdb 6.0 for AIX. I found version 6.8 in the net at http://www.perzl.org/aix/index.php?n=Main.Gdb. Our Admin installed it.
I can now step through the program and watch variables. I even can write gdb-commands directly in the console-view. yabadabadooooooo
Hope that helps to others as well. Can not tell, what was really the winner-action.
But each answer gives more new questions. Now I got 3 of them.
When I start the debug config I have to click restart in the toolbar to come really in the main procedure. Is it possible to come directly in main without restarting?
On AIX our programs are first preprocessed for embedded sql. The preprocessed c-source is put in another directory. When I duble-click the line to set a breakpoint, I get the warning "unresolved breakpoint" and in the gdb-console I see, that the break is set to the preprocessed source which is wrong. Is it possible to set the breakpoints on the right source?
We are using CICS on AIX. With the xldb-Debugger and the CDCN-command of CICS we manage that debugging is started, when we come in our programs. Is it possible to get that remotely (in plink) with gdb-eclipse as well?
I wouldn't normally take a shot in the dark on a question I can't really test the answer to, but since this one has sat around for a day, I'll give it a shot. It seems from looking at:
http://wiki.eclipse.org/TM_and_RSE_FAQ#How_can_I_do_Remote_Debugging_with_CDT.3F
...that even if the CDT has changed since that wiki page was made, you should still be able to change the debug command to:
ssh remotehost gdb
instead of using TM which uses gdbserver. This will probably be slightly slower than the TM remote debugging since that actually uses a local gdb, but on the other hand this way you won't have to NFS or SMB mount your source code to make it available to the local debugger (and if you're on a LAN it probably won't matter anyhow).
There's also a reference TCF implementation for linux, which you may or may not have any luck recompiling for AIX, but it allows for remote debugging if gdbserver is otherwise not available:
http://wiki.eclipse.org/DSDP/TM/TCF_FAQ
tried also to remotly debug an aix-appl with windows eclipse-cdt-gdb.
Got blocked at the end with unix/windows path-problems. Maybe my result can help u a little further - maybe you already got it work. I'm interested in your comment. asked on eclipse news portal- following the answer of martin oberhuber (thanks again) tried dsp dd (also blocked with path problem) and set an request in eclipse bugzilla.
here the link to news:
http://www.eclipse.org/newsportal/article.php?id=406&group=eclipse.dsdp.tm
Here my bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252758
At the moment we still debug localy with xldb but I am trying ddd-gdb at the moment. At least locally gdb is running.