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.

#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.

Memory Leak Detection and ACE:

I’ve mentioned ACE before in a previous post evaluating portable runtime environments. It’s a pretty cool set of libraries that provides a portable OS abstraction layer and communication environment. If you write your application using ACE, it will compile and run on a whole host of system types… but I digress.

One problem with ACE is that it conflicts with the Windows leak check code. If you define _CRTDBG_MAP_ALLOC before the ACE headers, you will get build errors like the following:

1>..\include\ace\os_ns_unistd.h(154) : error C2059: syntax error : ‘constant’

What’s happening is that the ACE headers try to enable the leak detection code themselves, which causes the overridden memory functions to conflict with the original versions. In essence, ACE is trying to define malloc (for example) after crtdbg.h has already overridden it.

So, how do you get your application to build with leak detection and ACE? Define _CRTDBG_MAP_ALLOC after the ACE headers (Remember: the ACE headers must always be included before other headers… another complaint I have).

#include “ace/ACE.h”

#define _CRTDBG_MAP_ALLOC

// Include other headers here

#include <crtdbg.h>

Okay, your application should compile now. Run it and look at the output window. For a simple application that does nothing but return, this is what I see:

Detected memory leaks!
Dumping objects ->
{178} normal block at 0×00CDBD78, 50 bytes long.
Data: <—TEST—     > 2D 2D 2D 48 45 4C 4C 4F 2D 2D 2D 00 CD CD CD CD
{173} normal block at 0×002EAAC8, 8 bytes long.
Data: < . > C0 A1 2E 00 CD CD CD CD
{172} normal block at 0×002EAA78, 20 bytes long.
Data: <4 Z Z > 34 90 F3 5A 0A 01 00 00 F3 17 DA 5A 03 00 00 00
{171} normal block at 0×002EAA18, 32 bytes long.
Data: < Z ] > C4 91 F3 5A C0 FB 5D 00 FF FF FF FF 00 00 00 00
{170} normal block at 0×002EA9B8, 32 bytes long.
Data: < Z ] > C4 91 F3 5A 88 FB 5D 00 FF FF FF FF 00 00 00 00
{169} normal block at 0×002EA958, 32 bytes long.
Data: < ZP ] > B4 91 F3 5A 50 FB 5D 00 FF FF FF FF 00 00 00 00
{168} normal block at 0×002EA910, 8 bytes long.
Data: < Z > D4 91 F3 5A 00 00 00 00

… Truncated for sanity (30 more leaks follow) …

Object dump complete.
The program ‘[14288] simple.exe: Native’ has exited with code 0 (0×0).

These are very likely false-positives, but they are annoying. There are other problems too:

1. There are no file/line numbers printed, so we can’t track down the code to verify if the errors are real or not.
2. File and line numbers don’t show up for errors outside of ACE (the first leak is mine).
3. All this output adds noise that can hide other memory leaks (I wish Microsoft would add a way to suppress errors we don’t care about… props to Valgrind for doing this).

Anyways, all of this is quite frustrating. I was hunting around on the ACE newsgroup for solutions and could only find this thread:

“In general, we track memory issues on Windows using Purify, so you might try going that route.”
Douglas Schmidt

“Correct. This memory tracking scheme and the ACE restrictions onheader file placement are at odds here. You have two choices:

1. Use a different memory tracking scheme such as Purify, which Doug
suggested.

2. Develop, or sponsor, necessary changes to remove ACE’s restrictions
on header file placement.”
Steve Huston

So there you have it: ACE and Window memory leak detection don’t play nice together. I hate encountering a problem without a viable solution… it bugs me (no pun intended). I even tried modifying the ACE headers with marginal results (it came close to compiling). Oh well…

• 500 x 750 JPEG
• 500 x 750 PNG

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!

Okay, let’s be more specific:

(gbd) b Plugin::Initialize
Breakpoint 4 at 0×8046194: file Source/Plugin.cpp, line 89

Okay, that looks better, but which Plugin.cpp file did GDB put the breakpoint? How do we know it’s the file for the plugin we want?

If we used namespaces, then we can get more specific:

(gdb) b MY_PLUGIN_A::Plugin::Initialize
Breakpoint 5 at 0×8050039: file Source/Plugin.cpp, line 130

We can see from the address and line number that the previous breakpoint was at the wrong place. Okay, moving on…

Setting Breakpoint in Templates:

Templates can be much harder to set breakpoints in because we have to specify the exact prototype for the fully-defined template. We as programmers are used to the compiler handling the template type stuff for us, so it can be difficult to guess the correct type.

For example, assume we have some abstract class BarAbstract that uses the template Foo<> to make it concrete. Now assume we’re really clever and we want to hide this from the users of our class. We could use a typedef to hide the true type:

typedef Foo<BarAbstract> Bar;

Now, all the user needs to do is instantiate Bar without a thought to the Foo<> template.

int DoSomething()
{
Bar b;
return b.Baz();
}

So far so good? Okay, now how the heck do you set a breakpoint in the Baz() method of class Bar?

The quick answer: use objdump, c++filt, and grep to find the complete definition that GDB will need.

$ objdump -t libMyLib.so | c++filt | grep ‘BarAbstract.*Baz’
0000d2d6 w F .text 0000000a     MY_PLUGIN_A::Foo<MY_PLUGIN_A::BarAbstract>::Baz()

Now, simply copy-n-paste the full method definition to GDB when setting the breakpoint:

(gdb) b MY_PLUGIN_A::Foo<MY_PLUGIN_A::BarAbstract>::Baz()
Breakpoint 6 at 0×8048890: file Source/Bar.cpp, line 355

That’s it! Happy debugging!

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’