I am trying to debug a program in Java using SpringSource ToolSuite. Every time it gets stuck at AWTAutoShutdown.class. I have tried hitting F8 to step out of whatever is happening but it seems like there is a thread locking up somewhere. I understand this is kind of a vague question but has anyone seen this before? Where can I start looking to solve this problem?
So one thread is suspended with a ThreadDeath exception. Perhaps STS is suspending because there is an uncaught exception, instead of on a breakpoint. There is a setting so that you can turn off suspension on uncaught exceptions, which I only want about half the time anyway. Turn that off and see if your thread dies and gives you something more useful in terms of operation (or an error).
Related
Asking a very generic question, and it seems like this is the same problem asked from the other side. But I'm wondering if there is any other reason, other than an uncaught exception, can make an Android app crash?
That is, is it true that if I were to have a big try catch surrounding every thread, there would always be a chance to do some cleanup right before things blow up?
Thanks!
I am running a Java Program in command prompt
The normal course is after successfully executing the program it comes back to prompt .. what are the possible reasons it will not come back to prompt after successfully executing the program
why is it not coming back to prompt after execution
usually it comes back but sometimes it doesn't...
This sounds like a race condition. Something in your application's shutdown sequence is non-deterministic, and it works or does not work depending on various platform specific (and possibly external) factors. There is probably no point figuring out what those factors are (or might be), since it won't help you fix the problem.
Only difference is in RAM hard disk capacity mine is slower.. Can it be possible reason?
These could be factors, but they are not the cause of the problem. So focus on figuring out what makes your application non-deterministic.
As others have said, without more information (and relevant code) we can only guess.
When the application has failed to shut down, get it to give you a thread dump. Or try shutting it down while it is attached to a debugger. These may allow you to get some clues as to what is going wrong.
Finally, the brute force solution is simply to have the main method (or whatever) call System.exit(0) on its way out. But beware of the possibility of files not being flushed, etc if you do that.
Because it's not finishing. If it's sometimes happening and sometimes not, my instinct is that you have some sort of race condition. Probably one of your cleanup steps is hanging if another action has or hasn't been taken.
Without source code this will be hard to debug.
There could be an active thread still running which is not in "daemon" mode. For example, if you have a Swing GUI and all of the frames are closed the Event Dispatch thread is still active so the JVM will not exit.
We're having the classic spring/hibernate/mysql stack running in Tomcat 5.5. Once in a while we're getting a deadlock when the attempt times out to lock a table row. Some kind of deadlock exception is thrown.
The exception is clear and the stack trace indicate what went wrong. But it doesn't show the other thread which is holding the actual lock. Unless I know what that thread is doing it's all just a needle in a haystack.
QUESTION: Is there a way to find the other thread ?
Thanks !
Jan
Try using the following command in MySQL next time you see a deadlock. This should show you the last deadlock.
SHOW INNODB STATUS
Typically when you see a deadlock on your application server the logs show only the victim thread (the one which was rolled back). Since the other thread has completed no exception is thrown. You need to go back to your DB to recreate the transactions.
Once you have a capture from your DB for where the deadlock occured then you can investigate further.
not sure if you've figured it out already but if it's a deadlock, thread dump would be of great help here. Depending on what OS the application is run and on your priviledges to access it, you can generate it in many ways.
on *nix sending QUIT signal to the process ('kill -3 pid') would do the work
using jconsole/jvisualvm has an option to get it
using standard jdk jstack (consider -F -l options) will do the trick
if you are lucky to be on solaris pstack will help a lot
Once you've got it, analyse locked/waiting threads to find a deadlock. You can do it manually or using some existing analyzers that utilize deadlock detection algorithms. Btw jvm has one builtin and it can give you the idea right in the thread dump.
If I can help more just let me know.
good luck.
regards,
baz
if it's a code problem you could try to connect to the running process using jconsole and detect the deadlock.
If you need to find the thread that holds a lock, you can do this in Eclipse through the debug view. Have a look at http://archive.eclipse.org/eclipse/downloads/drops/R-3.1-200506271435/eclipse-news-part2b.html and scroll down to 'Debugging locks and deadlocks'.
The locks owned by a thread as well as the lock a thread is waiting for can both be displayed inline in the Debug view by toggling the Show Monitors menu item in the Debug view drop-down menu. Threads and locks involved in a deadlock are highlighted in red.
Is it possible to kill a Java thread without raising an exception in it?
This is just for testing purposes - I want to simulate a case when the entire computer dies mid-thread.
Note - I saw a deprecated Thread.destroy() method, but the documentation says it never got implemented in the first place.
No. There is the deprecated, 'inherently unsafe' Thread.stop() method, but as its comment emphasizes, things could be left in an deeply corrupted state, and the ThreadDeath Error is still thrown inside the thread.
Sun's explanation of the problems with stop(), which can manifest long after it appears to work, is at:
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
Wouldn't killing the JVM process (or yanking the plug) be a better simulation of computer death?
There is no portable method. You might try to call "kill -9" (or your local equivalent) on the whole java process, if you want to suppress the running of finalizers and shutdown hooks.
You won't get any kind of repeatable results out of such a test, but it might be interesting to perform such tests a few thousand times if your program is writing to the file system or a database and might leave inconsistent data structures when being killed.
Or you could... kill the process. (ie, if this is Linux, send a kill -9 signal to the process).
Beware the race issues if you're trying to test something - if you hoping to crash badly - it might only do it once a month if you're particularly unlucky.
What is the point of your test? Java offers no guarantees about what happens on an exit, apart from attempting to run shutdown hooks if the exit is a "clean" one
It sounds akin to trying to test your program's behaviour in the case it goes OutOfMemory; there's nothing you can do about it and no way of telling deterministically what will happen
Is there any reason you can't use Thread.suspend()? It will stop the thread so you can examine the state when the thread is interrupted.
You could also use Thread.stop() although that risks throwing multiple ThreadDeathExceptions. You can wrap it int try/catch/finally blocks, but there are no guarantees.
Thread stop() throws an error in the thread. ThreadDeath
The only way to simulate an application dying mid thread is to call System.exit().
However, this is pretty random so you have to perform the test many times to have any confidence you application behaves correctly no matter where it dies.
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).