After serving a few requests my eclipse has started breaking on processWorkerExit() method.
As per this link I know how to suppress the breaking of eclipse but is there any reason why the code is breaking on this line. Can there be a memory leak in such a case?
Tomcat 7.0.27
Eclipse 3.7.2
JDK 7.0.02
Answer is here: OpenJDK breaks on processWorkerExit with no breakpoint
In debug mode in eclipse by default, break on uncaught exceptions is
checked. Since you don't have a catch method here, it's likely that an
uncaught exception is being thrown and the debugger is breaking for
you immediately before the exception is thrown. You can turn it off in
preferences under Java->Debug.
The reason the debugger is stopping on that line is because there is an exception being thrown by the code within the try{} block, and that particular line of code is the next executable line of code after the exception is thrown. You can almost certainly see the stack trace of that exception in the console window, because by default an uncaught exception that bubbles up to Thread.run() will be sent to stderr.
As for your question about whether there can be a memory leak (or more likely, this being Java, a resource leak): the answer is yes, there could be. But there is nothing in that code to indicate that there is. If there were such a leak, it would almost certainly be because there is incorrect exception handling inside the task implementation.
I had this same problem. It breaks in your try/catch clause if you have one if you don't log the exception. Try inserting a breakpoint or output to LogCat like this :
try
{
//HERE I'VE PUT ALL THE FUNCTIONS THAT WORK FOR ME
Log.e("tag", "Sth passed!");
}
catch (Exception e)
{
//The task failed
Log.e("tag", e.getMessage());
}
If you don't have try/catch block put it like in above code. In LogCat you can see the last line of code that was run before exception it will help you to locate the error in your code just like this :
08-28 05:49:52.321: E/SQLiteDatabase(834): at java.lang.Thread.run(Thread.java:841)
Related
I have an OOM error(Perm Gen is full), problem is when I am logging the error message into the log file, error occurs while the classloader is loading the exception handling class.
You shouldn't handle errors as your application is in abnormal state:
https://docs.oracle.com/javase/7/docs/api/java/lang/Error.html
Differences between Exception and Error
This answer explains scenario where you might want to do it though:
Catching java.lang.OutOfMemoryError?
You can either throw this error to handle where you're using it or you can put a try catch block around your logic(code) and you can log the error inside the catch or finally block.
I have a java application that's mysteriously dying without any exceptions in the logs. I'm running it in the background via a bash script that wraps a nohup like below:
nohup java -Xms6g -Xmx6g -jar myapp.jar 2>> stderr.txt >> /dev/null & echo $! > /tmp/myapp-pid
The java application is quite memory intensive and so has been configured with 6GB of heap space (running on a 64 bit JVM). It runs fine for about 8 hours and then silently dies. No exceptions in the logs, nothing.
From the main method the app enters an infinite while loop, polls AWS SQS for messages and processes them. This is all wrapped in a try-catch and I am logging in the catch. The application seems to exit after it completes a while loop as it logs the last line. e.g. The application will always end with 'Successfully processed'.
while(true) {
try {
// Logic to poll SQS and process the message
} catch (MyCustomException e) {
// Write to SQS dead letter queue (was throwing at this point)
// Delete message from original SQS
} catch (Throwable e) {
LOG.error(...);
} finally {
LOG.info("Processing time was...");
}
}
I'm not sure where to begin as I would've thought it would log something. Can anyone provide some pointers or maybe some JVM settings to configure so that I can start investigating?
I am wondering if things outside the code may be causing the error. Like perhaps a JVM crash?
Update
It seems like this was indeed a programming error. I didn't think it was causing the issue so I hadn't added it to the code path above (just added it now) but I did have another catch clause catching a custom Exception that I had created. Within that catch I was attempting to move the SQS message to the dead letter queue but did not have permission to it and thus was throwing inside the catch which I wasn't handling.
Thanks for all those that helped in suggesting what may have gone wrong!
Without having more code it is hard to say what actually happens.
But per definition of finally it is executed always, which means also in case of failure. Maybe you are just missing the exception which is written before it.
Try to move the finally call inside the 'try'-block.
while(true) {
try {
// Logic to poll SQS and process the message
LOG.info("Successfully processed");
} catch (Throwable e) {
//As mentioned in the comments try for debugging to log on info level here as well.
// Maybe error level is disabled (although this should be
//very unlikely since error normally is written too when info is written.
LOG.info(...);
} finally {
//Clean up.
}
}
This are two ideas which may help you further investigate your issue.
Don't your system run out of memory? Try running the application from wrapping script, logging the exit code - echo $! >&2 .
Also running dmesg could tell you if oom killer chose ypur application as a victim.
I made many research on this subject without found a real answer.
Try to imagine a program which execute a multi thread calling a Callable.
For that, we launch an ExecutorService with a specific timeout which invoke all process.
So we have a try...catch block with multiple exception :
CancellationException for a timeout
ExecutionException if an exception is raised in the thread
InterruptedException for an abrupt stop...
Is the philosophy to log an message only, or to log the message and the throwable (so the stacktrace) ?
To sum up, should we do this :
} catch (CancellationException ce) {
logger.error("Timeout. Process cancelled", ce);
}
or just log the message error ?
Is stacktrace considered to appear only for bugs ?
Thank you.
For coding you should stick with the following pattern:
} catch (CancellationException ce) {
logger.error("Timeout. Process cancelled", ce);
}
The reason is that the Throwable captures the complete context of an error. If you omit parts of that context from the logger you'll never be able to access it later on if you need it. Even the Throwable class included with Java has been modified over time to include things like chained and suppressed exceptions. So even if you only want the message from this throwable you still might want to see the full stack traces for suppressed exceptions and exceptions causes.
On the output side, I think you can make that case that for some exceptions the stack trace is not important. In some cases the target audience must not or does not want to see exception stack traces. For these cases should leverage the features of the framework to change the published output to please the target audience. If the needs change over time you can tweak logging configuration without having to fix the application code.
This is a minor annoyance I have when debugging with Eclipse. With "Suspend execution on uncaught exceptions" checked, the debugger will normally suspend a thread right where the exception was thrown. Exceptions on the Event Dispatch Thread, however, cause it to pause on the last line of EventDispatchThread.run(). There is no useful information about what the exception is or what caused it until I resume the thread to allow the stack trace to print to the console.
Debug the following code in Eclipse to demonstrate:
public class SuspendOnUncaughtTest {
public static void main(String[] args) {
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
((Object) null).toString();
}
});
}
}
And here is what it looks like after the exception is thrown:
EDIT 10/21/2011: I guess there's nothing weird going on with Eclipse or the Java debugger, it's just that exceptions are caught and rethrown in EventDispatchThread.pumpOneEventForFilters(int). I suppose there's no way to tell Eclipse to "suspend execution on exceptions that are going to be caught and possibly rethrown". Too bad.
Is see a similar result in NeteBeans, but Thread.setDefaultUncaughtExceptionHandler() may be useful in this context. There's an example here.
As far as I can tell, there is no solution to this. Eclipse is behaving correctly, the correct behavior is just annoying.
I had this issue and found something that worked for me.
I am using Kepler, and was able to stop this by going to the breakpoints tab of the debugger perspective and deselecting the checkbox on the EventDispatchThread.
An IOException is thrown and, for some reason, it's impossible to catch. Have a look at the code below. The stack trace says an IOException is thrown when calling the "apply"-method. The exception doesn't, however, get caught by the catch clause. When I try to catch an IOException instead, Eclipse complains saying: "Unreachable catch block for IOException. This exception is never thrown from the try statement body"
Why is this happening?
Code:
try {
action.apply();
}
catch (Exception e) {
System.out.println("Fail");
}
Here's the stacktrace:
java.io.IOException: Unable to download JavaScript from 'somesite' (status 404).
at com.gargoylesoftware.htmlunit.html.HtmlPage.loadJavaScriptFromUrl(HtmlPage.java:1023)
at com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:967)
at com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
at com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:225)
at com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
at com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
at org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
at org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
at org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
at org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
at org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
at org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
at org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
at org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
at com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
at com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
at com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
at com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
at com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:420)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:303)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:360)
at org.openqa.selenium.htmlunit.HtmlUnitDriver.get(HtmlUnitDriver.java:228)
at org.openqa.selenium.htmlunit.HtmlUnitDriver.get(HtmlUnitDriver.java:216)
at org.openqa.selenium.internal.seleniumemulation.Open.handleSeleneseCommand(Open.java:36)
at org.openqa.selenium.internal.seleniumemulation.Open.handleSeleneseCommand(Open.java:22)
at org.openqa.selenium.internal.seleniumemulation.SeleneseCommand.apply(SeleneseCommand.java:33)
at Action.runSeleniumAction(Action.java:235)
at SessionDriver.runSession(SessionDriver.java:192)
at SessionDriver.run(SessionDriver.java:123)
the apply() method fully handles the exception and does not rethrow it. If it did it would be marked as "public void apply() throws IOException".
The compiler warns you about this, since it would result in inaccurate error handling if it didn't.
Right, the apply() method itself isn't throwing that exception. Something else inside that apply method() is, and that something prints the complete stack trace instead of the "fail" message that you've decided is somehow better.
As you can see in the stacktrace, your code is missing, therefore you can't catch the exception. My guess is that SessionDriver.run() is called from a different thread.
Have you tried Selenium-RC? It should be able to catch these errors and pass them on to the test case.
You're using eclipse - so easiest way to get to the source of the exception is to run your application in debug mode and set a breakpoint on java.io.IOException. So whenever this exception is thrown somewhere in the running VM, eclipse will stop the application and show you thread, class and line of code (if available).