Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Just My Code Stepping in Visual Studio

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: C++ Just My Code Stepping in Visual Studio

#31

Post by phendrenad2 »

neverfone wrote: post #27
waynecochran wrote: post #14

Great. Now if they can actually fix the debugger to lock onto a single thread when stepping thru multithreaded code. Currently when you set a breakpoint and step, you’ll be jarringly switched back to the breakpoint when another thread hits it. The solutions now are tedious : https://visualstudio.uservoice.com/forums/121579-visual-stud...

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That really doesn't seem like what people would expect by default.

It’s a UX issue, not a behavior issue, I think. What I would do is... after the user presses the “step” button, until the user presses the “continue normally” (or whatever the free run button that ends the debugger is in VS), if breakpoints are encountered in other threads, they are quietly opened in new tabs, places under the current debugger tab. Maybe flash the tab a bit to let the user know this has happened. I don’t think VS has tabs for the debugger interface, so it would need that added.

Re: C++ Just My Code Stepping in Visual Studio

#32

Post by 1_player »

waynecochran wrote: post #14

Great. Now if they can actually fix the debugger to lock onto a single thread when stepping thru multithreaded code. Currently when you set a breakpoint and step, you’ll be jarringly switched back to the breakpoint when another thread hits it. The solutions now are tedious : https://visualstudio.uservoice.com/forums/121579-visual-stud...

The problem is that the normal implementation of a breakpoint/step is replace a single byte with a 0xCC opcode (INT 3), which will be hit by every thread. Making it lock onto a single thread would require a conditional breakpoint, checking the thread ID every time that code path is executed, which might potentially use a lot of CPU. I'm not sure that kind of conditional breakpoint has hardware support.

It's definitely possible to implement, but not as easy as using a regular INT 3 instruction.

Re: C++ Just My Code Stepping in Visual Studio

#33

Post by neverfone »

phendrenad2 wrote: post #31
neverfone wrote: post #27

Earlier quoted context omitted.

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That really doesn't seem like what people would expect by default.

It’s a UX issue, not a behavior issue, I think. What I would do is... after the user presses the “step” button, until the user presses the “continue normally” (or whatever the free run button that ends the debugger is in VS), if breakpoints are encountered in other threads, they are quietly opened in new tabs, places under the current debugger tab. Maybe flash the tab a bit to let the user know this has happened. I d…

Hmmph, I see what you're saying, that sounds like it could work.

I think the tab flashing is the critical detail, otherwise you would be confused why things are deadlocking.

Re: C++ Just My Code Stepping in Visual Studio

#34

Post by jamesfmilne »

neverfone wrote: post #27
waynecochran wrote: post #14

Great. Now if they can actually fix the debugger to lock onto a single thread when stepping thru multithreaded code. Currently when you set a breakpoint and step, you’ll be jarringly switched back to the breakpoint when another thread hits it. The solutions now are tedious : https://visualstudio.uservoice.com/forums/121579-visual-stud...

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That really doesn't seem like what people would expect by default.

GDB can do that already.

   (gdb) help set scheduler-locking 
   Set mode for locking scheduler during execution.
   off  == no locking (threads may preempt at any time)
   on   == full locking (no thread except the current thread may run)
   step == scheduler locked during every single-step operation.
      In this mode, no other thread may run during a step command.
      Other threads may run while stepping over a function call ('next').

Re: C++ Just My Code Stepping in Visual Studio

#37

Post by giancarlostoro »

jamesfmilne wrote: post #34
neverfone wrote: post #27

Earlier quoted context omitted.

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That really doesn't seem like what people would expect by default.

GDB can do that already. (gdb) help set scheduler-locking Set mode for locking scheduler during execution. off == no locking (threads may preempt at any time) on == full locking (no thread except the current thread may run) step == scheduler locked during every single-step operation. In this mode, no other thread may run during a step command. Other threads may run while stepping over a function call ('next').

GDB has all sorts of super powers but is there a GUI that works well with GDB?

Re: C++ Just My Code Stepping in Visual Studio

#38

Post by renox »

giancarlostoro wrote: post #37
jamesfmilne wrote: post #34

Earlier quoted context omitted.

GDB can do that already. (gdb) help set scheduler-locking Set mode for locking scheduler during execution. off == no locking (threads may preempt at any time) on == full locking (no thread except the current thread may run) step == scheduler locked during every single-step operation. In this mode, no other thread may run during a step command. Other threads may run while stepping over a function call ('next').

GDB has all sorts of super powers but is there a GUI that works well with GDB?

Yes, gdb --tui ;-)

Re: C++ Just My Code Stepping in Visual Studio

#39

Post by Arnavion »

jamesfmilne wrote: post #34
neverfone wrote: post #27

Earlier quoted context omitted.

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That really doesn't seem like what people would expect by default.

GDB can do that already. (gdb) help set scheduler-locking Set mode for locking scheduler during execution. off == no locking (threads may preempt at any time) on == full locking (no thread except the current thread may run) step == scheduler locked during every single-step operation. In this mode, no other thread may run during a step command. Other threads may run while stepping over a function call ('next').

The VS debugger can freeze threads too. Neither gdb nor VS can help AFAIK if the user doesn't want to freeze the other threads.

Re: C++ Just My Code Stepping in Visual Studio

#40

Post by legulere »

1_player wrote: post #32
waynecochran wrote: post #14

Great. Now if they can actually fix the debugger to lock onto a single thread when stepping thru multithreaded code. Currently when you set a breakpoint and step, you’ll be jarringly switched back to the breakpoint when another thread hits it. The solutions now are tedious : https://visualstudio.uservoice.com/forums/121579-visual-stud...

The problem is that the normal implementation of a breakpoint/step is replace a single byte with a 0xCC opcode (INT 3), which will be hit by every thread. Making it lock onto a single thread would require a conditional breakpoint, checking the thread ID every time that code path is executed, which might potentially use a lot of CPU. I'm not sure that kind of conditional breakpoint has hardware support. It's definitel…

Should be doable with help from the operating system to have thread-local storage for the code segment when debugging.
Post reply on HN