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.
Related
I've a java process running and unfortunately one thread inside the process is hung.
I found the Thread id which was hung using jstack, however I was unable to find any references on how to interrupt this thread using the id?
Is it possible to Interrupt/Stop a thread from console (or basically outside the process) by using the processId and ThreadId?
Any suggestions on how to tackle this?
PS : I don't want to kill the process as its just one thread which is hung. Also, neither do I want to make code changes to Stop/Interrupt the thread. I just want to kill it, so all its resources can be released.
There's no baked-in way to kill a thread within the JVM, at least not a deliberately implemented one.
Having said that, if you have started your JVM with the appropriate parameters, so that you can start a remote JMX session to it, you can actually suspend the thread and inject a RuntimeException into it, which will almost surely terminate it (unless you are doing something gnarly with RuntimeExceptions in it).
See this blogpost.
P.S. You would never start your JVM in production allowing rogue JMX connections though, and if you're not in production, I'd guess that the above approach is not of much help to you.
Android OS never stops surprising me. I wish i'd know whats the rule opon which they decide weither to kill your Thread or not while your app is on background. This is very confusing, at first i was sure that they run Services code on special service threads, and any thread created from the Service Thread is not eliminated when app goes to the background, but then when i Log Thread.currentThread() i see that both Activity's code and Service's code runs on the same main Thread, while as documented, services can run on background while activities cant.
How is this whole thing work? how do they decide which Thread to kill and which not? how do they decide weither an Object is in use or that its memory can be freed? at first i expected it to work like in standart Java enviroment but they got everything changed in an unclear and not very documented way...
anyone here can give me a reference to a good article about this issue or even better can explain this to me?
For starters, when dealing with Services you should probably read the Service doc. A relevant line from there is:
Note that services, like other application objects, run in the main thread of their hosting process.
All of this is quite well documented actually. The Android OS does not kill specific threads, only entire processes. You can read more of this in the Process Lifecycle section of the same document.
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.
I'm trying to debug a problem in my Java application that throws no errors, no exceptions and doesn't even crash the app (it seems the failure happens in a separate thread).
The problem seems to be inside a call to a library function (it's JAXBContext.newInstance(String) if that matters). The program will reach the line just before the call, but not the one just after it. My catch blocks are not entered and the program just continues to run.
The problem happens while trying to render an XML response to a web request that came in via Struts. The request has been handled and the code should marshal the response object. The client gets a response right away (so the code doesn't seem to hang in a loop), but it's just empty.
I have set a breakpoint just before the problematic line but the debugger just runs over it, I haven't a clue why.
I'm using eclipse and the application runs inside an OSGi container (Apache Felix) that was started with -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y. From within Eclipse I then use the Debug settings for "Remote Java application" to connect the debugger.
What are techniques to get at such a problem?
Probably an obvious question, but are you sure you are catching Throwable? An unchecked exception could easily cause the thread in question to die (assuming no one above you in the call stack is catching it either.)
Since you are suspending the VM on startup with your debug arguments, I assume you have confirmed that the debugger is attaching correctly. The fact that you say the debugger skips right past the call is very suspect. Are you able to hit any breakpoints in this application? What about in this Class? What about in this thread?
How did you narrow down the line in question without the debugger? println/debugging to a file?
Can you paste a code snippet of the method in question?
You could confirm the theory that the thread is dying by creating a second thread before the problem occurs and joining it to the thread you think is dying. Then the second thread's run() method would be invoked when the thread in question exits, and you'd know it died (but would still not know why.)
In answer to your general question, when I have a bug in a Java app that I can't reproduce in the debugger (which happens from time to time for various reasons), I incrementally modify my code with sysout printlns or output to files. If necessary, I may also modify the code my code is invoking. If you don't have the source code to the code you are invoking, you can try one of the many BCI frameworks to inject your byte code into the methods in question. It's a tedious process, but only happens occasionally.
You could try getting a Thread Dump - that will tell you if any methods are blocking (e.g. waiting for input). [Edit: re-reading your original question, getting a thread dump probably won't help as it looks like nothing is actually blocking. But I'm leaving it here as I find it useful in many other situations!]
If you think the error is happening in another thread you could also set an UncaughtExceptionHandler to try and catch it.
If you're sure the problem is somewhere within that method, you could try looking at the JAXB source code.
EDIT:
Well, if it gets really bad you can build your own private copy with debugging instrumentation. I hope you won't have to resort to that.
perhaps inside the call there is an infitite loop happening and this is why you get no further - but this might not cause a crash (unless memory is being used in each loop).
I have a program 'foo' running different threads, fooT1, fooT2, .. fooTn.
Now if I want write another program 'bar', which could kill the thread fooTr, is that possible?
Reason: One of the thread fooTr tracks product license. If this thread is killed; one may run this product indefinitely. And killing 'foo' itself is tolerable as 'foo' as that is exactly what is being done on license expiry.
System: Fedora Distribution of Linux
Note: The commands which start JVM and program foo are placed in /etc/init.d and anyone who has a decent knowledge of rc.1/rc.2/rc.3 structure can change/add the starting parameters to these.
I hope my question is clear. If not, I can always edit it.
Actually the java debugger will allow you to kill a thread by injecting an exception into it. I was just trying to work out how to use this feature to kill a thread without wiping out the whole jvm, when I came across this question. If you run the jvm with command line options like:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8888 your.app.Main
and connect the debugger with something like:
jdb -attach 127.0.0.1:8888
you can type:
threads
to get a list of the running threads, and use the kill command to kill a running thread. The bit I'm currently not sure about is the syntax of this kill command, I have tried the obvious:
kill 0xe2e new java.lang.IllegalArgumentException("er");
and I get the messages:
killing thread: Swank REPL Thread
Thread not suspended
Expression must evaluate to an object
("Swank REPL Thread" is the thread I want to kill, and yes, I've tried suspending it first ;)
Still my inability to use the java debugger aside, it looks to me like a thread can be killed at random. Maybe you can just make sure you ignore all exceptions and keep running and that will be enough, but I'm not sure about that.
To my knowledge it is not possible to do this directly. What you could consider however is to create some kind of service on your 'foo' that can be called from 'bar' to kill the thread. There are, of course, hundreds of ways to implement this. My first thought would be to do this using RMI.
You could do this even without a separate application. Write your own startup class, which performs a pass-through of parameters to the original startup class of the application. Your class's main method though would create a thread that periodically checks the list of all threads (e.g., Thread.getAllStackTraces or Thread.enumerate), finds the offending thread, and invokes stop() on it. Although Thread.stop is deprecated, it still works.
Another option is to run the application under a Java debugger, say, jdb and then suspend/kill the required thread. You could also add parameters to the application's startup so that the JVM can be attached to, then attach jdb to the running JVM and suspect/kill the thread.
Until now isn´t possible to run to diferent programs in the same JVM, but some people is investigating it, in order to reduce the startup time and the memory and cpu usage of diferent java programs runing in the same machine