Viewing Call Stack?

[Tommy Vercetti]

I have a complex threading deadlock scenario that I've been able to
reproduce in the debugger. I hit break and look at the call stack which
should tell me what I need. Except I only get the very bottom of the
call stack:

KERNEL32.DLL!7c573b28()
KERNEL32.DLL!7c573b50()
boost_thread-vc71-mt-gd-1_31d.dll!boost::detail::condition_impl::do_wait()
Line 198 + 0xf C++
Sniper.exe!boost::condition::do_wait<boost::mutex> () Line 150 + 0xd C++

This is C++ (not Managed or .NET C++). I'm using Boost threads, Dev
Studio .NET 2003 (VC++ 7.1). Lack of a working call stack makes
debugging extremely difficult. Are there any ways to get it working?

[Steve McLellan]

Hi,

That sounds like a pretty reasonable call stack for a thread that's not
doing very much. Have you had a look at the other threads? The debugger
toolbar has three drop downs - the middle one lists the threads you've got
running. Maybe some of the others will give you some ideas.

Steve

"Tommy Vercetti" <ve*********@hotmail.com> wrote in message
news:es**************@TK2MSFTNGP11.phx.gbl...

I have a complex threading deadlock scenario that I've been able to
reproduce in the debugger. I hit break and look at the call stack which
should tell me what I need. Except I only get the very bottom of the
call stack:

KERNEL32.DLL!7c573b28()
KERNEL32.DLL!7c573b50()
boost_thread-vc71-mt-gd-1_31d.dll!boost::detail::condition_impl::do_wait()
Line 198 + 0xf C++
Sniper.exe!boost::condition::do_wait<boost::mutex> () Line 150 + 0xd C++

This is C++ (not Managed or .NET C++). I'm using Boost threads, Dev
Studio .NET 2003 (VC++ 7.1). Lack of a working call stack makes
debugging extremely difficult. Are there any ways to get it working?

[Tommy Vercetti]

I guarantee you that there is more to the call stack. I didn't launch a
thread with an entry point of the boost::condition object. I know the
entry point function of that thread and it's not on that call stack.

Yes, I can switch to other threads. Some of them are stuck in the same
place and others are doing other tasks. It's hard to diagnose the
problem without seeing the important call stacks though.

Steve McLellan wrote:

Hi,

That sounds like a pretty reasonable call stack for a thread that's not
doing very much. Have you had a look at the other threads? The debugger
toolbar has three drop downs - the middle one lists the threads you've got
running. Maybe some of the others will give you some ideas.

Steve

"Tommy Vercetti" <ve*********@hotmail.com> wrote in message
news:es**************@TK2MSFTNGP11.phx.gbl...

[Steve McLellan]

One thing to try as a workaround is to stick some debug logging where you
think the problem is (before / during / after locked sections). Presumably
this is a one-off problem, and it may not be worth spending a long time
getting the debugger to behave. Otherwise, I don't know. Good luck with it.

Steve

"Tommy Vercetti" <ve*********@hotmail.com> wrote in message
news:eU**************@TK2MSFTNGP11.phx.gbl...

I guarantee you that there is more to the call stack. I didn't launch a
thread with an entry point of the boost::condition object. I know the
entry point function of that thread and it's not on that call stack.

Yes, I can switch to other threads. Some of them are stuck in the same
place and others are doing other tasks. It's hard to diagnose the
problem without seeing the important call stacks though.

Steve McLellan wrote:

Hi,

That sounds like a pretty reasonable call stack for a thread that's not
doing very much. Have you had a look at the other threads? The debugger
toolbar has three drop downs - the middle one lists the threads you've got running. Maybe some of the others will give you some ideas.

Steve

"Tommy Vercetti" <ve*********@hotmail.com> wrote in message
news:es**************@TK2MSFTNGP11.phx.gbl...