In a method I am debugging, I am spawning a new thread. I need to debug the execution of this new thread rather than the parent thread. How can I do this in eclipse?
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.
Put a breakpoint on "run" method of the new thread. That would halt execution once the thread starts.
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
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.
Start debug session.
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.
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.
Related
Testing a multithreaded application with JUnit5, the automated tests run just fine.
But in manual debugging, the environment misbehaves, and I would like to know how to get it to act as it should.
IntelliJ (using the Java VM + its debugger) has two general options to suspend on breakpoints: either "All" = all threads, or "Thread" = the current thread only.
(Which thread is "the current thread" may be unclear and causing issues, but that's been discussed separately, see other issues here on stackOverflow.)
Wanted behaviour:
a breakpoint to suspend a specific thread, and the JUnit test environment, which is part of the IDE debugging.
Actual behaviour:
either all threads are suspended, even those which should be running
or only a single thread is suspended, and JUnit #AfterEach/#AfterAll annotations kill the resources currently debugged, terminating the threads that should be running, etc.
How to achieve the Wanted behaviour?
(Environment: AdoptOpenJDK8, AdoptOpenJDK11 in Java 9 mode, IntelliJ 2020.3, JUnit-Jupiter 5.7.0)
You can use two breakpoints. The one you're really interested in and another one in your unit test (somewhere between calling the code under test and cleaning up). Set both to only suspend the current thread.
I set a breakpoint in the shutdown hook, and debug it in intellij. But it looks like it has some timeout that it would automatically exit after some time.
In cases of System Shutdown, operating system allows a fixed amount of time for shutdown and exit. In other cases application waits for shutdown-hook to complete like ctrl C , System.exit(status)
It is expected that shutdown-hook to finish their work quickly.
i have many threads running in my application, but
i want to debug just only one thread. i'm using eclipse, is that possible? i just saw that stuff in visual studio and in c#
Thank you for your help and pacience.
Identify the thread that you want to debug and name it using currentThread().setName("myThreadName"). Then set a conditional breakpoint on currentThread().getName.equals("myThreadName").
Take care though as thread pooling can introduce some complications to your debugging process.
If you open up the debug perspective, the window on the top left ("Debug") will list all the threads and let you pause them individually.
Supposed I have an application that can spawn multiple threads if needed for doing tasks ... so nothing special. I use Eclipse to write and debug Java applications. A thread (lets call it "async task") is immediatly respawned after it leaves the run() method (so there is bug and I want to find the reason for this behavior).
My question, if I pause this thread "async task" using the eclipse IDE (debug perspective ..) is there way to find out where this thread was originally started (for example using the Debug view or any other)? Because I want to know who spawns this thread (without making a text search or something like this).
Is there a good way to get this information?
I would set a breakpoint at Thread.start() and enable a condition
Whenever a thread named "async task" is started the condition is evaluated to true and the thread that invokes the start method is paused. Then you can see in the stacktrace from where the call came.
Had a similar problem in production and wrote a litte java agent that logs the stack of every thread start. So the system can run and you get the info live in the log. That helps a lot, when you have many threads. https://github.com/xdev-software/thread-origin-agent
You can't check whether new thread start or not by using debuger since debug will hang your entire JVM.
You can put some logs and check how threads works there.
Is there any mechanism within the Eclipse debugging environment to see the state of synchronization locks held and processes waiting?
You can show the state of object monitors in Eclipse's debugger. You can find a short, clear tutorial here. For each thread, Eclipse can show you the monitors the thread owns and those it is waiting for.
Update 2020-01-20: The link above no longer works. Here's a link to cached version on the Internet Archive.
As suggested here you could (if you run the Sun JVM) perform the following steps:
launch jconsole or jvisualvm (both present in the bin-directory of your JDK-installation,
attach to the process you suspect has locked up
go to the Threads pane. There is a "Detect Deadlock" button
Another option: I would suggest add logging in order to "debug" your code. Sometimes it will be more intuitive.