So here’s a cool feature of GNU’s implementation of libc: you can get a stack backtrace (as an array of strings) dynamically in your code. This can be really useful when trying to determine the code path taken when an error occurs. Most times, it’s faster to just run the code in a debugger and use it to display a backtrace, but there are instances when doing it programmatically is your best option. For example, you could get a backtrace in your application’s exception handler and use it to augment error log messages.
First, you need to include execinfo.h to your code:
#include <execinfo.h>
Next, call the backtrace() function to get an array of void pointers that represents the current stack (the pointers are the return addresses for each stack frame).
void* tracePtrs[100];
int count = backtrace( tracePtrs, 100 );
The backtrace() function returns the number of entries in the array (read the man pages for more info about the array size).
Finally, you need to resolve the function names associated with the pointers. You have 2 options: backtrace_symbols() and backtrace_symbols_fd(). Both of these methods resolve the pointers to strings, but the difference is that backtrace_symbols() allocates the strings on the heap while backtrace_symbols_fd() writes the strings to a file descriptor that you can read. Just keep in mind that backtrace_symbols() won’t work if the heap has been trashed.
Here’s an example using backtrace_symbols():
char** funcNames = backtrace_symbols( tracePtrs, count );
// Print the stack trace
for( int ii = 0; ii < count; ii++ )
printf( “%s\n”, funcNames[ii] );
// Free the string pointers
free( funcNames );
NOTE: Make sure you call free() on the array of strings returned from backtrace_symbols().
For more information, here’s a good article from the Linux Journal.
The Windows development environment provided by VisualStudio has some neat tools for detecting memory leaks in code. You simply #define _CRTDBG_MAP_ALLOC before including your headers, and #include <crtdbg.h> as the last header:
#define _CRTDBG_MAP_ALLOC
// Include header files here
#include <crtdbg.h>
Then, you call _CrtDumpMemoryLeaks() before your application exits. If your program exits at many points, you can alternatively call _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ) at the beginning of you application, which will cause the leaks to also be printed when it exits. The results are printed to the Debug Window and look like the following:
Detected memory leaks!
Dumping objects ->
C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\leaktest\leaktest.cpp(20) : {18}
normal block at 0×00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
Cool, Huh?! However, some libraries don’t play nice with this, as I explain below.
I saw a Linux logo I liked on Google Images a while back, but all instances of it have been removed. I got tired of searching, so last night I hacked around in Photoshop and recreated it.
Debugging C++ templates is difficult. Debugging C++ templates with GDB can be an act of torture for even seasoned GDB users. I like GDB, but there are some tricks you should know when using it to debug templates. In this post, I deal with setting breakpoints.
Breakpoint Basics:
Setting a breakpoint in GDB is supposed to be simple. Here we set a breakpoint at line 50 in file main.cpp:
(gdb) b main.cpp:50
Breakpoint 1 at 0×804937a: file main.cpp, line 50.
We can also use the function name and GDB will attempt to find the correct location for us:
(gdb) b DoSomething
Breakpoint 2 at 0×8049334: file main.cpp, line 150
Simple, right? Just wait…
Breakpoint Gotchas:
GDB’s breakpoint logic is pretty handy for simple projects, but it can break down fast when things get more complicated.
For example, let’s say your application is plugin-driven, with each plugin being a separate library. Now assume each plugin has a Plugin.cpp file under it’s own Source directory. Try to set a breakpoint in the Initialize() method of the Plugin class:
(gdb) b Initialize
Breakpoint 3 at 0×8049717: file main.cpp, line 230
Oops! There is an Initialize() method in main.cpp and GDB thought that’s where we wanted to put it: wrong!
Recently, I was trying to run a GUI front-end to Valgrind (Valkyrie) from within a chroot’d environment on Fedora 9. It failed to run, and after some searching I figured out the problem. Here’s the story.
First, I made sure to disable access control from outside the chroot (warning: make sure you understand the security implications of this!):
[dev]$ xhost + localhost
localhost being added to access control list
Next, I entered the chroot’d environment and attempted to run the application, but it failed with the following error:
[chroot]$ valkyrie
valkyrie: cannot connect to X server 127.0.0.1:0.0
The problem is that the X server is configured by default NOT to listen for remote connections (usually on port 6000). I verified that this was the problem by leaving the chroot and trying to connect via telnet:
[dev]$ telnet 127.0.0.1 6000
Trying 127.0.0.1…
telnet: connect to address 127.0.0.1: Connection refused
The way to fix this on previous Fedora installations was to use gdmsetup. However, this is no longer available. Hunting through the KDE config files I found the solution: change the arguments passed to the X server after login in the kdmrc file.
NOTE: I’m using fluxbox as my desktop environment… KDE is used for the Fedora login screen, which is why we are messing with its config files.
[dev]$ sudo su
[root]# cd /etc/kde/kdm
[root]# cp kdmrc kdmrc.old
[root]# vi kdmrc
On my system, the problem was this line:
ServerArgsLocal=-br -nolisten tcp
I simply changed it to:
ServerArgLocal=-br
I restarted my X server and tried to connect with telnet again (this time with success):
[dev]$ telnet 127.0.0.1 6000
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
Then, I once again disabled X access control (`xhost + localhost`) and everything worked fine. Hope this helps!
EDITED 11/17/2008: Changed ‘xhost +’ to ‘xhost + localhost’
Microsoft has started to release developer information for Windows 7 (the follow-on to Windows Vista). Of particular interest to me is the Windows 7 Developer Guide. It discusses many of the new features that will be available when this new version of Windows is released.
Of particular interest to me are the changes to DirectX 10, Media Foundation, and the new DirectX 11. Here are some highlights.
DirectX 11:
- “…resource creation and management has been optimized for multithreaded use, enabling more efficient dynamic texture management for streaming.”
- Several improvements have been made to the high-level shading language (HLSL), such as a limited form of dynamic linkage in shaders to improve specialization complexity, and object-oriented programming constructs like classes and interfaces.”
DirectX 10 improvements:
- “The pipeline also introduces the geometry shader stage, which offloads work entirely from the CPU to the GPU. This new stage enables you to create geometry, stream the data to memory, and render the geometry with no CPU interaction.”
- Predicated rendering performs occlusion culling to reduce the amount of geometry that is rendered. Instancing APIs can dramatically reduce the amount of geometry that needs to be transferred to the GPU by drawing multiple-instances of similar objects. Texture arrays enable the GPU to do texture swapping without CPU intervention.”
Media Foundation improvements:
- “…Media Foundation has been enhanced to provide better format support, including MPEG-4, as well as support for video capture devices and hardware codecs.”
- “In Windows 7, Media Foundation provides extensive format support that includes codecs for H.264 video, MJPEG, and MP3; new sources for MP4, 3GP, MPEG2-TS, and AVI; and new file sinks for MP4, 3GP, and MP3.”
- “In Windows Vista, Media Foundation exposed a relatively low-level set of APIs. These APIs are flexible, but may not be appropriate for performing tasks. Windows 7 adds new high-level APIs that make it simpler to write media applications in C++.”
Here’s great diagram of the Direct3D 9.0 graphic pipeline (thanks Amanda for bringing this to my attention). I know DirectX 10 is out, but this diagram serves as a good reference for anyone interested in the nitty-gritty of a 3D graphics pipeline.
