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!

Jello

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");
   ...
}

Zurn

Bad idea: using output functions often serializes your threads because cout uses locks. This can destroy the problem you are trying to find. – Logging

Then replace cout with fprintf(stderr, ...). – Zurn

Still not good enough, any type of io is dangerous when debugging serious synchronization problem, but the idea is right and the output object can be selected in the runtime depending on situation – Wagonage

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.

Py

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 :).

Wagonage

I'll invite you to debug deadlocks/race conditions/... on my distributed multithreaded system :) You have a good point about having logging services designed in from the start! – Py

If you have your logging services designed in advanced you don't need me :) – Wagonage