How to debug a multithreaded application?

[a_nisanth]

Can anyone please tell me how to debug a multithreaded application in VC++? Do I require any other third party s/w to perform debugging?

Thanks,
Nish

[miteshpandey]

AFAIK you don't require anything special except the Visual Studio IDE to debug multithreaded applications

Just put breakpoints at appropriate places. One thing to note is that when a break point is reached in a thread and you want to reach another break point in another thread simply press F5 till the break point in the another thread is reached. Which break point is reached first will however depend upon the placement of your break point and the timings as well.

[JVene]

miteshpandey is certainly correct, you have what's required in visual studio, going back as far as version 4.x.

There are some 'tricks' though. Miteshpandey already pointed out the basics.

One of the views you can open is a 'threads' panel. This allows you to select which thread you want to focus on. When a breakpoint fires, your debugger will focus on the thread that reached that breakpoint, your variables window will show local values for that thread's call to the function (where the are locals), and the call stack will represent that thread's stack.

You can switch threads to 'focus' upon in the thread window when the debugger has 'broken into' the execution.

There are some 'side effects' to be aware of, however, and I'm not personally familiar with any debuggers superior in these regards, though I've not toured the majority of other tools. For one, if you step through execution from a breakpoint, it is possible that the debugger will switch focus from one thread to another without you expecting it. If it seems to you that execution has branched to a code position without good reason, it may just be that the debugger has stepped execution on another thread, has switch focus to it, and is showing you THAT thread. This can be disconcerting until you're accustomed to it.

There is a feature in the thread window to 'freeze' a thread, which can help with this problem sometimes.

I do feel there's room for improvement for threaded debugging. Perhaps there's a debugger with a feature that permits multiple trace windows, each focused on a thread independently, meaning that the notion of 'switching focus' is alleviated. For now, Visual Studio, essentially, can only show the stepped execution of one thread at a time, which is why it must 'switch' focus to another thread when appropriate. If they ever think of it, or accept the recommendation, to permit multiple streams of execution in the debugger, with multiple, independent, thread focused windows for code tracing, variable display, stack display, etc.. it will be at once both easier and more complicated to debug. Easier, in the sense that you can depend upon a consistent focus on one thread at a time, for a given display. More complicated in that with several code windows on display, several variable windows on display, multiple stack windows on display (even tabbed), one would wish for 3 or 4 monitors at high resolutions just to watch everything. I currently use two at 1280 x 1024, and still it's not enough.

[a_nisanth]

Thank you very much.

[Arjay]

It also helps to have a logging mechanism that logs entry/exit of functions with details of parameters. I've got one that allows indenting every time a function is entered (and 'outdenting' on function exit) and is configurable for depth of logging.

The advantage of logging to help debugging is that you get to see the order that the threads execute. I use the debugger to debug as much as possible, but as others have mentioned sometimes it interrupts the natural flow. So when it's important not to interrupt the flow in order to repro the issue, I turn on the logging.

[exterminator]

It also helps to have a logging mechanism that logs entry/exit of functions with details of parameters. I've got one that allows indenting every time a function is entered (and 'outdenting' on function exit) and is configurable for depth of logging.Is that indentation logic inside your logging framework or do you manually control that everytime? (My guess would be the logging lib itself but just to confirm - how do you handle that?)

[Arjay]

Is that indentation logic inside your logging framework or do you manually control that everytime? (My guess would be the logging lib itself but just to confirm - how do you handle that?)Sorry to take so long to reply, I had to dig up the source. :)

A bit of architectural background.

The logging framework is a threadsafe singleton. When a logging event is logged using the Trace method, the log message gets pushed on to a queue where a secondary thread dispatches the log entry consumers (by default there are console, debug, and file consumers).

To use the logging within the application, your implementation classes can create a CTraceMsg member variable or use multiple inheritance and derive from CTraceMsg. Classes can set the initial indent level during initialization so output from various classes can be displayed at various[indent] depths.

In addition, indent level can be controlled on the Trace level as well. You can choose to use the current depth, increment, decrement, or increment + new line, or decrement + new line.

In addition, each trace message can be assigned a detail level and the log consumer can be set to ignore or log different details. This can be set during program startup or changed during runtime.

I find it easier to debug trace output when it's indented, so I generally inc[indent] on method start and dec on method end.

For example here is code that initializes an engine that executes tests:


HRESULT CEngine::Initialize(...)
{
Trace( LDL_SPARSE, LIT_INC_NL, _T("CEngine::Initialize") );
HRESULT hr = S_OK;

if(FAILED(hr = m_ProcessMgr.Initialize( ...) ) )
{
return hr;
}

if(FAILED( hr = InitializeWindowTrapMgr() ))
{
return hr;
}

Trace( LDL_SPARSE, LIT_DEC_NL, _T("CEngine::Initialize - End") );

return hr;
}


The trace output would be (assuming the forum doesn't reformat it):


CEngine::Initialize
ProcessMgr::Initialize() 2, 2000
ProcessMgr::UpdateProcessListNT()
ProcessMgr::UpdateProcessListNT() - End
ProcessMgr::Initialize() - End

CEngine::InitializeWindowTrapMgr
CWindowTrapMgr::InsertWindowTrap Error, #32770
CWindowTrapMgr::InsertWindowTrap - End
CWindowTrapMgr::InsertWindowTrap Just-In-Time Debugging, #32770
CWindowTrapMgr::InsertWindowTrap - End
CEngine::InitializeWindowTrapMgr - End

CEngine::Initialize - End

[Arjay]

Well, it formatted it close. Everything was correct except for:


CEngine::InitializeWindowTrapMgr - End


This line should have been indented.