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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…