score:39

Accepted answer

Put a breakpoint on "run" method of the new thread. That would halt execution once the thread starts.

score:4

In addition to Erik Kaju's answer. If you are debugging CDT (this might be applicable for Java as well, I am not sure about that) then

  1. Put a breakpoint on run() method (or its equivalent). Or any point at which you are sure that the required threads and the not-required thread (the ones which will be removed by the filter) both are running.
  2. Start debug session.
  3. When the breakpoint in run is hit, you can go to another breakpoint, enable that breakpoint if it was disabled. Then right click on the breakpoint -> go to Filters, now you can select the thread you want the breakpoint to be remain enabled for and you can uncheck the rest of the threads. So this breakpoint will only be hit for that particular thread.

The drawback is this procedure has to be repeated for every debug session. If anyone can provide short cut for it then that would be nice.

score:4

in your eclipse debug window you can jump threads to land on the desired worker thread number and continue your step over(F6) sequential exploration. enter image description here

score:189

In addition to Shamit Verma's answer:

When dealing with debugging multi-threaded Java applications, it is better not to use standard breakpoints that suspend just the thread where the breakpoint is set. Defining a standard breakpoint in your application, will only break the related thread. The other threads will be still running. In eclipse debugger for some reason will cause the debugger to skip breakpoints if other threads already started.

The solution for debugging Java:

Define a breakpoint in desired thread (@ Run() method i expect..), right click at the breakpoint -> breakpoint properties.

In breakpoint properties dialog tick "Suspend VM" instead of "Suspend thread".

If you do like this your entire VM will be suspended in case of a breakpoint is reached.

In C/C++ CDT, use set scheduler-locking on :

As @Employed Russian says in answer-to-other-question, the GDB command:

set scheduler-locking on 

will cause other C/C++ threads to remain suspended while allowing the current thread to step. This command can be executed in Eclipse/CDT Debug by suspending program execution and opening the 'Debugger Console' perspective and typing: set scheduler-locking on It can later be returned to normal with: set scheduler-locking off

See GDB documentation for more information on scheduler-locking and non-stop mode, which allows other threads to run while stopping a single thread.


Related Query

More Query from same tag