Make the debugger stick to the current thread instead of jumping around between threads!
Please, please fix this! Debugging multithreaded applications is hard enough as it is, without having to manhandle the debugger just so it does the obvious thing you want.
I'm sure everyone knows what I'm talking about. You're stepping through your function, and suddenly your instruction pointer jumps somewhere unexpected and none of the variable values make sense and you realize you're not in the thread you thought you were in. It's really tough or impossible to get back to where you were in the thread you cared about. Or you set a breakpoint two instructions down, and it may be hit by a completely different thread. Or you Ctrl-F10 to step to a point in your code a few lines down, and again you're in some other thread without warning.
There are only two tedious solutions currently:
a) Freeze all threads in the thread window except the one you care about. This leads to locking up many times, and it's a pain to unlock and continue where you started. Essentially you can thaw all threads, put a breakpoint after the line in your thread that's locked, and F5 over and over until that breakpoint is hit in the thread you care about.
b) Breakpoint filters: create a breakpoint, right click on the breakpoint, click Filter, and enter ThreadId = 7740 (your thread id from the threads window). This is hugely tedious, especially when your workflow involves setting and unsetting many breakpoints.
1) Make sure F10, F11, Ctrl-F10, etc., which are intended to be stepping in the current region of code NEVER switch threads, unless an explicit breakpoint is hit on another thread! This involves setting the thread filter to the current thread on whatever internal breakpoint Visual Studio is setting to achieve the desired stepping functionality.
2) Ctrl-F9 (or similar shortcut) to create a breakpoint with the current thread as its filter.
These two changes would make debugging multithreaded applications sooo much better!
Thanks a lot for your attention.
Thank you for using Visual Studio and for your commitment to improving it. We are currently evaluating whether we will be able to address this suggestion in a future release. Thanks for capturing the pain points you feel when stepping through multithreaded applications while debugging. We will be providing an update soon.
Additionally, I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated. So if you hit a breakpoint, disable it, and then begin stepping you should not stop on a different thread. If you have other breakpoints in your application and another thread hits one, then you will be debugging in the mixed thread state as described in this item.
Program Manager, Visual Studio
DARK Guy commented
I can't believe we're in 2017 and this functionality hasn't been worked on yet. To me, it seems that MS just fakes listening to its users, because it doesn't as it can clearly be evidenced here.
Robert Schmidt-Cisternas commented
Still broken in VS2017 - the debugger is useless when debugging a single thread out of multiple. I'm using .NET Core and ASP.NET Core.
Bob Bryan commented
I too agree that the proposed functionality is absolutely critical to debugging multi-threaded code. Have you ever tried to debug multi-threaded code and watch the instruction pointer stay on the same line (which causes one to think, gee - did I press the F10 key hard enough?), jump forwards, as well as jump backwards every time the step key is pressed? This is all due to multiple threads running thru the code. The debugger needs to provide a little bit of extra functionality that allows developers to control how multiple threads are run to make debugging the code easier, and without having to freeze each and every thread and then unfreeze those same threads later on - which can be quite time consuming.
This is what I would suggest:
Provide a default multiple-threaded debug mode that single steps thru the code without switching to a different thread. That makes the code easier to debug by single-stepping through the code. As others have pointed out, that is how IBM and others do it. There are two sub-modes of this mode. The first sub-mode, the default, stops all other threads from executing through the code, which in effect forces the code to be single-threaded at that point. It should do this by freezing the other threads. The developer would have the option of unfreezing specific threads later on if he should want to debug 2 or more threads running thru the code. The 2nd sub-mode allows other threads to run through the code, but only threads from the thread of interest are allowed to hit breakpoints.
The non-default multiple-thread debug mode allows multiple threads to run through the code, as is the case now. Both the mode and sub-mode should be able to be changed via a context menu or some hot-key combination at any time while debugging.
This has been broken since the dawn of time. IBM's OS/2 debugger worked correctly, kdbg works correctly, xdbg or whatever AIX's full screen debugger was called worked correctly, eclipse with gdb works correctly, msvc is the only debugger I've ever used that has this crazy random thread context switching problem, and it has had it at least since this product was called visual c++. If they haven't been able to fix it by now, likely they're never going to. Makes you wonder how MS developers debug their software, obviously they don't use their own tools or they'd have fixed this problem by now.
I find current behavior not user friendly. There should be a flag "stick to current thread" which will automatically check $TID to match current thread ID. It is annoying to be throwned into other thread while you stepping across the code (in particular, it is hard to debug web servers that can serve parallel requests).
"This is broken then. At least it was in VS2012 (the version I'm currently stuck using). If you're single stepping through code that is being executed in parallel across multiple threads, there's no guarantee which thread you'll end up in next."
I can verify this behavior for the latest VS 2015 Community Edition and it annoys me to death. When I remote debug websites, I get 5-10 second VS hang ups when I suddenly step into my handler code.
Funny enough: I almost forgot about this problem, but then I got a new PC and recognized the massive delay while debugging. I checked my old client and found out, that it stays in the first thread I step into. I assume this change comes from a patch I installed years ago for my VS 2008 SP1 which had severe debug problems. I'm not sure, but I think it was this one: https://support.microsoft.com/en-us/help/957912/updates-for-visual-studio-2008-sp1-debugging-and-breakpoints.
Please fix this, it's such a senseless time killer! A "Stay in first/current thread" button/option would be nice and can't be that difficult to implement.
"I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated. So if you hit a breakpoint, disable it, and then begin stepping you should not stop on a different thread."
This is broken then. At least it was in VS2012 (the version I'm currently stuck using). If you're single stepping through code that is being executed in parallel across multiple threads, there's no guarantee which thread you'll end up in next.
Michael Zhang commented
Any Updates. This feature is going to be increasingly useful as multi-threading applications are exploding these days..
I vote for this request! do you have any update will this be implemented by Visual Studio team ?
Radim Brixí commented
I would recommend to implement another step into and step over debugging feature that would step only in one thread ignoring all steps in all other currently running steps that one would have to debug through as now. I wouldn't change the feature at all, I would just add a new one.
Would vote 3 votes but I'll all out! :(
Marián Špánik commented
If I recall correctly it had been a pain to debug a C++ code in #pragma omp parallel for as it kept switching between OpenMP threads. I am not sure whether the issue was fixed or is still present.
Steve Marton commented
Any feedback at all on this issue?
Steve Marton commented
I've noticed one particular case where the debugger fails to step normally.
In VS 2012 I placed a breakpoint in a function that is called by many threads.
Broke on one thread, disabled the breakpoint, and started stepping through.
Occasionally the instruction pointer would jump back to the location of the old breakpoint in another thread when that thread hit that instruction. This kept happening over and over as new threads hit that instruction, making it really hard to step through my thread of interest. I have a lot of these threads. This is a common scenario when you're running the same code wide across multiple cores.
It seems that the breakpoint was not correctly disabled on all the threads when I intended to disable it.
This might be the source of most of the headache I mentioned in suggestion 1). The rest of the time stepping seems to work reasonably, mostly.
Suggestion 2) is still super important, even if 1) is fixed!