What's a quick way to trace the entry and exit of functions in a Visual Studio 2005 c++ multithreaded program?

Question

I have intermittent crashes occurring in my ActiveMQ libraries due to the way I'm using the activemq-cpp API. It'd be much easier to debug the issue if I could observe every function being called leading up to the crash. Are there any quick ways to trace the entry and exit of functions in a Visual Studio 2005 c++ multithreaded program?

Thanks in advance!

Answer 1

Use a Tracer object. Something like this:

class Tracer
{
public:
  Tracer(const char *functionName) : functionName_(functionName)
  {
    cout << "Entering function " << functionName_ << endl;
  }

  ~Tracer()
  {
    cout << "Exiting function " << functionName_ << endl;
  }

  const char *functionName_;
};

Now you can simply instantiate a Tracer object at the top the function, and it will automatically print "exiting... " when the function exits and the destructor is called:

void foo()
{
  Tracer t("foo");
   ...
}

Answer 2

While the debugger is attached to a process, you can rightclick in the source code and select "breakpoint->add TracePoint", with the text you want (even some macro's are supplied).

The Tracepoint is in fact a BreakPoint with the "When Hit" field on some message printer functionality, and it doesn't actually break the process. I found it mighty useful: it also has a macro $FUNCTION, which does exactly what you need: print the function it is in (provided it has the debug info available...), and a $THREADID.

Answer 3

All the options above nice and can help you. But i can't see how setting TracePoing with mouse can help you in case you code have thousands of functions.
This kind of thing should be part of your regular programming work. When you writing a function you should think what trace message will help you to debug it.
You need to write/use existing logger that can be spitted to section (reader thread, worker thread, etc... )and different logging levels (error, warning,trace, verbose etc.. ). The good logger should be designed in the way it's not hurt you performance, this usually harm the verbosity, but complex synchronization problems usually can be reproduced unless the logging is very fast, like assigning a string pointer to the array that can be dumped after problem is reproduced. I usually start debugging with full trace dumped to the screen and if i lucky and bug reproduced this way, fixing the bug is trivial because i already have enough information, the fun starts when problem goes away and you need to play with verbosity in order to reproduce the problem.
I actually find debugging more creative and satisfying than code writing, but this is just me :).