I am looking at a backtrace in gdb, and it looks really cluttered because of all the calls made into the standard library and boost. Eg. I see boost::bind and std::allocator on the call stack, and several other similar calls into the standard library or Boost.
I think I would find it helpful to have backtrace show me just the functions explicitly defined in my program. Better yet, it would help further if I could quickly configure the backtrace command to show or hide std and boost calls as and when I need them.
Any idea how to hide boost from the call stack altogether or to configure backtrace to turn boost logging on and off?
There is no built-in way to do this.
It can be done, though, by writing a Python "frame filter" that drops the frames that you don't care to see. This isn't particularly hard to do, but it requires writing a bit of Python code using the gdb Python API.
Related
I know wrapping with macro can be used for getting caller of a function. But when it comes to constructors it is not possible as far as I know. I am not using gcc so backtrace() function is not an option for me.
Edit:
I am using msvc.
An ideal tool for this is a debugger, which doesn't require you to make any modifications to your program.
However, if you really want to get the caller locally within the program, that is also possible - but not in standard C++ without using platform specific or wrapper libraries (Except by modifying the constructor and using the macro trick).
I am not using gcc so backtrace() function is not an option for me.
Then you will need to figure out which compiler you are using, and use whatever alternative they provide for stack unwinding.
There is a portable library libunwind which you might use, that works without access to backtrace. It doesn't seem to be ported to windows however.
I know wrapping with macro can be used for getting caller of a function
Wrapping the initialization should work in a similar fashion.
I need to get some debugging libraries/tools to trace back the stack information print out to the stdout.
Python's traceback library can be an example.
What can be the C++ equivalent to Python's traceback library?
This is platform-specific, and also depends on how you're compiling code. If you compile code with gcc using -fomit-frame-pointer it's very hard to get a useful backtrace, generally requiring heuristics. If you're using any libraries that use that flag you'll also run into problems--it's often used for heavily optimized libraries (eg. nVidia's OpenGL libraries).
This isn't a self-contained solution, as it's part of a larger engine, but the code is helpful:
https://svn.stepmania.com/svn/trunk/stepmania/src/archutils/Unix/Backtrace.cpp (Linux, OSX)
https://svn.stepmania.com/svn/trunk/stepmania/src/archutils/Win32/Crash.cpp (CrashHandler::do_backtrace for Win32)
https://svn.stepmania.com/svn/trunk/stepmania/src/archutils/Darwin/DarwinThreadHelpers.cpp (OSX)
This includes backtracing with the frame pointer with gcc when available and heuristic backtracing when it isn't; this can tend to give spurious entries in the trace, but for getting a backtrace for a crash report it's much better than losing the trace entirely.
There's other related code in those directories you'd want to look at to make use of that code (symbol lookups, signal handling); those links are a good starting point.
Try google core dumper, it will give you a core dump when you need it.
There's now cpp-traceback, it's exactly Python-style tracebacks for C++.
I have had success with libunwind in the past. I know it works well with linux, but not sure how Windows is, although it claims to be portable.
If you are looking for getting a 'stack trace' in case of crash, try 'google breakpad'
I have no experience with llvm or clang, yet. From what I read clang is said to be easily embeddable Wikipedia-Clang, however, I did not find any tutorials about how to achieve this. So is it possible to provide the user of a c++ application with scripting-powers by JIT compiling and executing user-defined code at runtime? Would it be possible to call the applications own classes and methods and share objects?
edit: I'd prefer a C-like syntax for the script-languge (or even C++ itself)
I don't know of any tutorial, but there is an example C interpreter in the Clang source that might be helpful. You can find it here: http://llvm.org/viewvc/llvm-project/cfe/trunk/examples/clang-interpreter/
You probably won't have much of a choice of syntax for your scripting language if you go this route. Clang only parses C, C++, and Objective C. If you want any variations, you may have your work cut out for you.
I think here's what exactly you described.
http://root.cern.ch/drupal/content/cling
You can use clang as a library to implement JIT compilation as stated by other answers.
Then, you have to load up the compiled module (say, an .so library).
In order to accomplish this, you can use standard dlopen (unix) or LoadLibrary (windows) to load it, then use dlsym (unix) to dynamically reference compiled functions, say a "script" main()-like function whose name is known. Note that for C++ you would have to use mangled symbols.
A portable alternative is e.g. GNU's libltdl.
As an alternative, the "script" may run automatically at load time by implementing module init functions or putting some static code (the constructor of a C++ globally defined object would be called immediately).
The loaded module can directly call anything in the main application. Of course symbols are known at compilation time by using the proper main app's header files.
If you want to easily add C++ "plugins" to your program, and know the component interface a priori (say your main application knows the name and interface of a loaded class from its .h before the module is loaded in memory), after you dynamically load the library the class is available to be used as if it was statically linked. Just be sure you do not try to instantiate a class' object before you dlopen() its module.
Using static code allows to implement nice automatic plugin registration mechanisms too.
I don't know about Clang but you might want to look at Ch:
http://www.softintegration.com/
This is described as an embeddable or stand-alone c/c++ interpreter. There is a Dr. Dobbs article with examples of embedding it here:
http://www.drdobbs.com/architecture-and-design/212201774
I haven't done more than play with it but it seems to be a stable and mature product. It's commercial, closed-source, but the "standard" version is described as free for both personal and commercial use. However, looking at the license it seems that "commercial" may only include internal company use, not embedding in a product that is then sold or distributed. (I'm not a lawyer, so clearly one should check with SoftIntegration to be certain of the license terms.)
I am not sure that embedding a C or C++ compiler like Clang is a good idea in your case. Because the "script", that is the (C or C++) code fed (at runtime!) can be arbitrary so be able to crash the entire application. You usually don't want faulty user input to be able to crash your application.
Be sure to read What every C programmer should know about undefined behavior because it is relevant and applies to C++ also (including any "C++ script" used by your application). Notice that, unfortunately, a lot of UB don't crash processes (for example a buffer overflow could corrupt some completely unrelated data).
If you want to embed an interpreter, choose something designed for that purpose, like Guile or Lua, and be careful that errors in the script don't crash the entire application. See this answer for a more detailed discussion of interpreter embedding.
What's the best way to implement an exception stack trace?
I found some kind of a solution using uncaught_exception() but it requires to add some code to every function.
I need something working on gcc under linux and windows
I don't think there's a cross-platform way to do it. On windows, look at the StackWalk method; on linux, man backtrace. This will get the information; it's up to you to format it.
I'm not sure that a reliable cross-platform method for unwinding the stack exists.
All the platforms/architectures that I've worked on have offered a way to walk the stack when an exception occurs and match addresses to function names. None of these are portable, but the reporting framework can written to be portable with the actual stack walking code remaining platform-specific (StackWalk on Windows or backtrace on Linux).
You might take a look at the libunwind project. I've never used or looked into this myself, so it may not be what you are looking for.
I implemented some code that generates the current stack trace as a string; take a look at the GetStackTrace() function that starts at line 1220 of this file if you are interested. The function works under Linux, MacOS/X, and Windows (note that I borrowed the Windows implementation from here, and that it takes an incredible amount of code to implement this feature under Windows.... bleah)
Debugging with gdb, any c++ code that uses STL/boost is still a nightmare. Anyone who has used gdb with STL knows this. For example, see sample runs of some debugging sessions in code here.
I am trying to reduce the pain by collecting tips. Can you please comment on the tips I have collected below (particularly which ones you have been using and any changes you would recommend on them) - I have listed the tips is decreasing order of technicality.
Is anyone using "Stanford GDB STL utils" and "UCF GDB utils"? Is there some such utils for boost data structures? The utils above do not seem to be usable recursively, for example for printing vector of a boost::shared_ptr in a legible manner within one command.
Write your .gdbinit file. Include, for example, C++ related beautifiers, listed at the bottom of UCF GDB utils.
Use checked/debug STL/Boost library, such as STLport.
Use logging (for example as described here)
Update: GDB has a new C++ branch.
Maybe not the sort of "tip" you were looking for, but I have to say that my experience after a few years of moving from C++ & STL to C++ & boost & STL is that I now spend a lot less time in GDB than I used to. I put this down to a number of things:
boost smart pointers (particularly "shared pointer", and the pointer containers when performance is needed). I can't remember the last time I had to write an explicit delete (delete is the "goto" of C++ IMHO). There goes a lot of GDB time tracking down invalid and leaking pointers.
boost is full of proven code for things you'd probably hack together an inferior version of otherwise. e.g boost::bimap is great for the common pattern of LRU caching logic. There goes another heap of GDB time.
Adopting unittesting. boost::test's AUTO macros mean it's an absolute doddle to set up test cases (easier than CppUnit). This catches lots of stuff long before it gets built into anything you'd have to attach a debugger to.
Related to that, tools like boost::bind make it easier to design-for-test. e.g algorithms can be more generic and less tied up with the types they operate on; this makes plugging them into test shims/proxies/mock objects etc easier (that and the fact that exposure to boost's template-tasticness will encourage you to "dare to template" things you'd never have considered before, yielding similar testing benefits).
boost::array. "C array" performance, with range checking in debug builds.
boost is full of great code you can't help but learn from
You might look at:
Inspecting standard container (std::map) contents with gdb
I think the easiest and most option is to use logging (well I actually use debug prints, but I think that's not a point). The biggest advantage is that you can inspect any type of data, many times per program execution and then search it with a text editor to look for interesting data. Note that this is very fast. The disadvantage is obvious, you must preselect the data which you want to log and places where to log. However, that is not such a serious issue, because you usually know where in the code bad things are happening (and if not, you just add sanity checks here and there and then, you will know).
Checked/debug libraries are good, but they are better as a testing tool (eg. run it and see if I'm doing anything wrong), and not as good at debugging a specific issue. They can't detect a flaw in user code.
Otherwise, I use plain GDB. It is not that bad as it sounds, although it might be if you are scared by "print x" printing a screenful of junk. But, if you have debugging information, things like printing a member of a std::vector work and if anything fails, you still can inspect the raw memory by the x command. But if I know what I'm looking for, I use option 1 - logging.
Note that the "difficult to inspect" structures are not only STL/Boost, but also from other libraries, like Qt/KDE.