When I run my code in debug mode in Eclipse, I'm able to find where the code breaks down, but an exception is not being shown on the council. In debug mode, I notice that after an exception is thrown, it seems to be swallowed up by the thread it's running on, and the program keeps going (or at least, keeps running. The program itself becomes unusable). Is there any way to get errors thrown in threads to be more visible?
I apologies if I've misinterpreted the path the debugger took through the code when it reached the exception. It seems to me that it is being caught by the thread. Regardless, whenever I have threaded code, I have a hard time finding out what the error was.
Using the Eclipse debugger, you can configure a breakpoint to break whenever some specified Exception is thrown.
To set this up:
On the debugger's Breakpoints tab, press the J! button. This will enable you to Add Java Exception breakpoint. You can also choose to suspend the JVM or thread that throws the Exception.
Just prior to your specified Exception being thrown, the debugger will suspend the thread or the JVM (all threads) depending on your choice. At this point, you can begin to diagnose the problem. It's not foolproof, but it will give you an excellent starting point to debugging your issue.
If you don't know what Exception is thrown, you can choose java.lang.Exception. This will pause for any Exception thrown.
You may want to register an UncaughtExceptionHandler with the thread, in which you can do the required logging.
Related
I thought that throwing exceptions from main() would definitely cause JVM to terminate, but I encountered a scenario where my Java application process did not terminate after an exception got thrown from main().
I'm still trying to figure out why JVM did not abort. Then I noticed that my code uses log4j but does not explicitly call LogManager.shutdown().
So, is it possible that, if LogManager.shutdown() is not invoked, JVM might not exit even when an exception is thrown from main()?
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).
I'm working on my usual projects on Eclipse, it's a J2EE application, made with Spring, Hibernate and so on. I'm using Tomcat 7 for this (no particular reason, I don't exploit any new feature, I just wanted to try that). Every time I debug my application, it happens that Eclipse debugger pops out like it has reached a breakpoint, but it is not the case, in fact it stops on a Java source file that is ThreadPoolExecutor. There is no stack trace on the console, it just stops. Then if I click on resume it goes on and the app works perfectly. This is what shows in the debugger window:
Daemon Thread ["http-bio-8080"-exec-2] (Suspended (exception RuntimeException))
ThreadPoolExecutor$Worker.run() line: 912
TaskThread(Thread).run() line: 619
I really can't explain this, because I'm not using ThreadPoolExecutor at all. Must be something from Tomcat, Hibernate or Spring. It's very annoying because I always have to resume during debugging.
Any clues?
The posted stack trace indicates that a RuntimeException was encountered in a Daemon thread. This is typically uncaught at runtime, unless the original developer caught and handled the exception.
Typically, the debugger in Eclipse is configured to suspend execution at the location where the exception was thrown, on all uncaught exceptions. Note that the exception might be handled later, lower down in the stack frame and might not lead to the thread being terminated. This would be cause of the behavior observed.
Configuring the behavior of Eclipse is straightforward:
Go to Window > Preferences > Java > Debug and uncheck Suspend execution on uncaught exceptions.
There's a more specific solution, which prevents Eclipse breaking on RuntimeExceptions thrown only from a given class.
Add a new exception breakpoint from the Debugging perspective
Go to its properties
Go to Filtering
In "Restrict to Selected Location(s)", click "Add Class"
Add java.util.concurrent.ThreadPoolExecutor
Untick the checkbox, meaning these will be ignored
This behavior is triggered by tomcat when a webapp is reloaded. It's part of tomcat "memory leak protection" feature that (among other things) forces the renewal of its threads.
This is now fixed from versions 7.0.54 and 8.0.6 of tomcat :
https://issues.apache.org/bugzilla/show_bug.cgi?id=56492
I have noticed that this often occurs after modifying server files (jsp or java) and STS has trouble reloading the application.
This usually leads to restarting the server in order to get it to get the changes synchronized.
After introducing JRebel - it appears to have gone away. So, I would like to think it is a reproducible issue in STS when hotswapping code in debug mode.
By removing the native hotswapping, it eliminates the issue with it breaking inside the ThreadPoolExecutor class.
Following on from this question https://softwareengineering.stackexchange.com/questions/37294/logging-why-and-what
I was wondering what actually happens to an error that occurs during the runtime of a Java Enterprise Edition applicaiton.
Does the JVM store a log of all the errors?
Or are the errors forgotten?
It is contingent where the output is directed. If output is getting pushed to a console window then yes...it is all but lost. An enterprise application however would be making use of a logging framework to deal with all output thus rendering any exception available within the logs provided by the framework.
Application servers usually have a big catch-all net to mop up any unhandled exceptions. However, if an exception is allowed to bubble up without it ever hitting a catch close, the thread it came from will die and the exception will be passed to the thread's UncaughtExceptionHandler, if one exists.
an error happens when the program is running. and is being handled by exceptions.
Exceptions : ignore the error, handel the exception, and go back to method that was called.
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).