🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Debugging threads in Visual Studio 2017

Started by
8 comments, last by Gnollrunner 5 years, 3 months ago

I was wondering if anyone knows how to debug a single thread in C++ with VS17.   My problem is I have a few threads running but I want to single step through the code in just one of them.  The default seems to be that it jumps around from thread to thread. Mind you I don't want to freeze the other threads but simply want the debugger to stop on only one when stepping though the code. I googled it and it seems like a few people have had this issue, but I didn't find a definitive answer.

Advertisement

Freezing threads was all i was going to suggest yeah. What's the reason freezing isn't going to work? It's suitable for most debugging in most scenarios i've encountered.

Well the threads interact with each other via std::mutex, std::condition_variable, etc...... The other threads have to do their job.  I've noticed several people have asked this question on various sites.

My only other suggestion would be to litter the code you want to step through with if statements checking the GetCurrentThreadID() value to some known value, maybe using a static value somewhere in the code that you can set at run time by hand. This would only allow you to run until you hit a breakpoint within one of these statements though.

I'm sure I can do some work around. It just seems like a huge pain in A$$ to do something that should be simple. Thanks for the suggestion though.

Are you trying to step multiple threads and/or multiple hit breakpoints?

Generally I only get in confusing situations after I have multiple threads stepping, because it is hard to predict which thread will complete its step next, otherwise they just do there own thing.

 

In the case of breakpoints, you could set a filter condition on the thread id or thread name if you need one in a piece of common code, but only want to stop a single thread rather than all of them using that code.

Naming threads is a great help just in general as well. Microsoft in Win 10 creators and VS 15.6 added a `SetThreadDescription`, otherwise the traditional way is to raise a special exception (0x406D1388) that debugger recognize as setting the thread name. See https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019

29 minutes ago, SyncViews said:

Are you trying to step multiple threads and/or multiple hit breakpoints?

Generally I only get in confusing situations after I have multiple threads stepping, because it is hard to predict which thread will complete its step next, otherwise they just do there own thing.

 

I really want to only step one thread. However I did have some break points earlier in some of the other threads. Perhaps that's the issue. I should try running it, only breaking the one thread I want to step through.  Maybe once you break a thread it flags it for stepping even if you aren't actually stepping from that thread.

37 minutes ago, Gnollrunner said:

I really want to only step one thread.

You could place a manual memory breakpoint administered for change on some thread-local variable, from that point when it breaks, you will be able to step up calls in that thread.

Bare in mind that if threads communicate, you freeze/stall them as well.

Actually I think I've figured something out (based on what @Sync Views said) . So yes, it seems if you never put a break point in a thread. it won't jump back and forth to that thread when stepping line by line.  So I guess the trick is you just have to put your first break point at the entry code of the thread you want to debug. Then when you hit it, you have to disable it if other threads are going to use that same code.

I still think they should have some better way to handle it. I mean it would be great if you could just select a thread to debug or turn off threads that you don't.  However I guess this is a good workaround for now.

This topic is closed to new replies.

Advertisement