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'
Related
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.
At the moment I'm working on a anticheat. I added a way to detect any hooking to the directx functions, since those are what most cheats do.
The problem comes in when a lot of programs, such as OBS, Fraps and many other programs that hook directx get their hook detected too.
So to be able to hook directx, you will most probabbly have to call VirtualProtect. If I could determine what address this is being called from, then I could loop through all dll's in memory, and then find what module it has been called from, and then sending the information to the server, maybe perhaps even taking a md5 hash and sending it to the server for validation.
I could also hook the DirectX functions that the cheats hook and check where those get called from (since most of them use ms detours).
I looked it up, and apparently you can check the call stack, but every example I found did not seem to help me.
This -getting the caller's address- is not possible in standard C++. And many C++ compilers might optimize some calls (e.g. by inlining them, even when you don't specify inline, or because there is no more any framepointer, e.g. compiler option -fomit-frame-pointerfor x86 32 bits with GCC, or by optimizing a tail-call ....) to the point that the question might not make any sense.
With some implementations and some C or C++ standard libraries and some (but not all) compiler options (in particular, don't ask the compiler to optimize too much*) you might get it, e.g. (on Linux) use backtrace from GNU glibc or I.Taylor's libbacktrace (from inside GCC implementation) or GCC return address builtins.
I don't know how difficult would it be to port these to Windows (Perhaps Cygwin did it). The GCC builtins might somehow work, if you don't optimize too much.
Read also about continuations. See also this answer to a related question.
Note *: on Linux, better compile all the code (including external libraries!) with at most g++ -Wall -g -O1 : you don't want too much optimization, and you want the debug information (in particular for libbacktrace)
Ray Chen's blog 'The old new thing' covers using return address' to make security decisions and why its a pretty pointless thing
https://devblogs.microsoft.com/oldnewthing/20060203-00/?p=32403
https://devblogs.microsoft.com/oldnewthing/20040101-00/?p=41223
Basically its pretty easy to fake (by injecting code or using a manually constructed fake stack to trick you). Its Windows centric but the basic concepts are generally applicable.
I want to use Shiny on a large-ish C++ code base, but I'd rather not add the required PROFILE_FUNC() calls to my source. I figure it's easy enough to write a script that for each source file, regex-searches for function definitions, adds a macro call just after the opening bracket and pipes the result to g++; but that seems an awfully obvious source-code instrumentation case, so much so I find it hard to believe no-one has come up with a better solution already.
Unfortunately, searching around I could only find references to LLVM / clang instrumentation and the odd research tool, which look like overly complicated solutions to my comparatively simple problem. In fact, there seems to be no straightforward way to perform simple automated code edits to C/C++ code just prior to compilation.
Is that so? Or am I missing something?
Update: I forgot to mention this "C++ code base" is a native application I am porting to Android. So I can use neither gprof (which isn't available on Android), Valgrind (which requires an older version of the NDK than what i'm using) nor the android-ndk-profiler (which is for dynamic libraries loaded by Android Activities, either Java or native, not plain executables). Hence my looking into Shiny.
Update 2: Despite previous claims I actually managed to build Valgrind on Android NDK r8e, so I settled on using it instead of Shiny. However I still think the original question is valid: isn't there any straightforward tool for effecting simple compile-time edits to C / C++ source files – some sort of macro preprocessor on steroids?
You can consider gprof or valgrind. If memory serves, gprof uses instrumentation and valgrind is a sampling-based profiler. Neither of them requires you to annotate source code.
You can use the android ndk profiler to profile C/C++ code
More info here
http://code.google.com/p/android-ndk-profiler/
You use gprof to analyse the results
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)
Recently, our big project began crashing on unhandled division by zero. No recent code seems to contain any likely elements so it may be new data sets affecting old code. The problem is the code base is pretty big, and running on an embedded device with no comfortable debug access (debug is done by a lot of printf()s over serial console, there is no gdb for the device and even if there was, the binary compiled with debug symbols wouldn't fit).
The most viable way would likely be to find all the division operations (they are relatively infrequent), and analyze code surrounding each of them to see if any of the divisor variables was left unguarded.
The question is then either how to find all division operations in a big (~200 files, some big) C++ project, or, if you have a better idea how to locate the error, please give them.
extra info: project runs on embedded ARM9, a small custom Linux distro, crosscompiled with Cygwin/Windows crosstools, IDE is Eclipse but there's also Cygwin with all the respective goodies. Thing is the project is very hardware-specific, and the crashes occur only when running at full capacity, all the essential interconnected modules active. Restricted "fault mode" where only bare bones are active doesn't create them.
I think the most direct step, would be to try to catch the unhandled exception and generate a dump or printf stack information or similar.
Take a look at this question or just search in google for info relating to exception catching in your particular environment.
By the way, I think that the division could happen as a result of a call to an external library, so it's not 100% sure that you'll find the culprit just by greping your code.
If I remember right, the ARM9 doesn't have hardware divide so it's going to be implemented in a function call the compiler makes whenever it has to perform a division.
See if your toolset implements the divide by zero handling in the same way as ARM's toolset does (it's likely that it does something at least similar). If so, you can install a handler that gets called when the problem occurs and you can printf() registers and stack so that you can determine where the problem is occurring. A possible similar alternative is that your small Linux distro is throwing a signal you can catch.
I'm not sure how you're getting your information that a divide by zero is occurring, but if it's because the runtime is spitting out a message to that effect, you always have the option of finding out where that is handled in the runtime, and replacing it with your own more informative message. However, I'd guess that there's a more 'architected' way to get your code to run (a signal handler or ARM's technique).
Finding all of the divisions shouldn't be hard with a custom grep search. You can easily distinguish that usage from other usages of the / and % character in C++.
Also, if you know what you are dividing, you could globally overload the / and % operator to have a __FILE__ and __LINE__ informing assertion. If using a makefile, it shouldn't be hard to include the custom operator code in all the linked files without touching the code.
You should use this as an excuse to invest in improving the debug-ability of your device - for both this problem and future issues. Even if you can't get live debugging, you should be able to find a way to generate and save off core dumps for post-mortem debugging (pinpointing the source or any unhandled exception immediately).
PC-Lint might help, it's like Findbugs for C++. It is a commercial product but there is a 30 money back guarantee.
Handle the exception.
Usually the exception will be handed a structure that contains the address that caused the exception and other information. You will probably have to become familiar with the microcontroller's datasheet or RTOS manual.
Use the -save-temps for gcc and find the relevant assembly for division in the generated .s file. If you're lucky it will be something fairly distinctive, possibly even a function call. If it's a function call you can use weak linking to override it with your own checked version. Otherwise locating the divisions in the assembly should give you a very good idea where they are in the C/C++ code and you can instrument them directly.
usually you could modify/override the divide-by-zero exception handler if you have access to the exception handler routines.
in case of ARM, the division is done by a library routine. and there are mechanisms to inform the user-code, when a divide by zero occurs.
see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka4061.html
i would suggest to provide a __rt_raise() as said in the page above.
__rt_raise(2,2) will get called when the divide routine detects a divide by zero.
so you can print the LR register.
and then use addr2line to crossref it against the source line
The only way to find those conditions is the usual:
try to reproduce the problem without looking at the source (as the bug already happened you should have info on the part of the program that is affected)
if found, check the source for this point and fix it, otherwise:
2.1. grep for each / not followed by a * or / (grep "/[^/*]" i think)
2.2. find the conditions for which the code is executed and reproduce it
The exception already has the address location of the offending divide by zero code. The CPU saves register contents when a exception occurs including the PC(program counter). Your OS should pass this information along (I assumes that is how you know it is divide by zero). Print the address and go look in your code. If you can print a stack trace it would be even easier to solve.
Another option would be to check the differences in your version control software between the last know working version and the first non working version. This should give you a limmited change set within which to search for the problem.