We get this question a few times a year so it seems fair to put in in the FAQ. User have noticed that they can set a breakpoint so that it stops only the thread that runs into it. If they try to step just this thread though, all the other threads stop as well. That is basically a design issue. The problem is that breakpoints are implemented with trap instructions. When you want to step a thread over a breakpoint, we have to replace the original instruction and step that thread (which really involves setting another, temporary, breakpoint at the beginning of the next source statement). However, if you have multiple threads running, and you lift the breakpoint, there is a chance that another thread will race through that breakpoint before we have a chance to reinstall it. So we really stop ALL the threads, and then step the one thread. Which leaves all the threads stopped. We're looking at this case, but we have a simple workaround that may be acceptable to users.

This involves setting up a tcl proc inside a .tvdrc file. The idea is to get a list of all the threads and subtract the current thread, or the one that is specified in the command, and then use the list to start those threads up again after the step. The proc looks like this:

In a .tvdrc file, you can set up the following code:


proc prefix_id {prefix ids} {
return [regsub -all {[^ ]+} ${ids} ${prefix}&]
}
proc tstep {} {
dfocus [prefix_id t [TV::focus_threads]] dstep
dfocus "([prefix_id p [TV::focus_processes]])-([prefix_id t
[TV::focus_threads]])" dgo
}


To use this, you would open up the Command Line interface (CLI - Tools->Command Line) If you are currently focused on the thread you want to step, you can enter the command

tstep

and check to see that the other threads are indeed running. If you have multiple threads you
want to step, you can use the dfocus command (abbreviated to 'f') to select
those threads first

f {1.2 2.3} tstep

which will step threads 1.2 and 2.3.


Regards,