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.
Related
Let me try to explain..We have a server running Jboss 5.1 with really many concurrent connections, and well, sometimes we need to restart and do some maintenance/release.
The problem is, sometimes we start up the server and it looks like some library just didn't load at startup time, or for some other reason, we keep getting NullPointerException without any stacktrace.. we do know the class it is thrown, but by checking the code, where nullpointers could for some reason be thrown, and even forcing a few exceptions, all of them have at least the stacktrace.
I found here in stackoverflow many answers telling about the JVM doing some optimizations but we have just started up the server.I don't believe it does any optimization even when the first exception is thrown.I have also checked for any relevant setStackTrace or codes like ex.toString()..which we also do not have.
So my question actually is, for what reason other than this optimization thing, could such exception be thrown without stacktrace?
EDIT:
My question is NOT related to the -XX:-OmitStackTraceInFastThrow, since it happens even at the first exception!
Use the -XX:-OmitStackTraceInFastThrow JVM argument.
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.
I've run into the issue where I have a program (not written by me, by someone else) I want to run 24/7, but sometimes it crashes. Normally, this wouldn't be an issue because I can simply create a process watcher that checks if it crashed, and then restarts it if necessary.
But, this particular program sometimes throws an exception and outputs it into the graphical interface that's integrated into it. In this instance, the program doesn't crash at all. The interface stays up, but the actual server functionality is unavailable.
Is there any way I can intercept this information from this process?
You want to use the Java Virtual Machine Tools Interface. I can't give you the code to catch your exception, but this is where to look. You'll have to do some detective work to find the class that throws the exception, or at least to find some indicator that it has been thrown.
Edit: You can also try calling the vendor to see if they know of a way. You can also look to see if it is writing the exception to a log file, which you could then watch.
This may or may not work, but if when the application displays it's error and the server stops working does the memory usage drop? If so you could probably just add some logic to your process monitor to call the windows command tasklist to see if the memory usage drops below some threshold. You'll have to check how much memory the program normally uses and how much it uses after the error though.
Since you said the server functionality stops working, another option could be to write a simple program that basically just pings the server how ever often you want to make sure it is still up. If not, kill the process and restart it.
I assume you have no access to the source code, so if it is outputting to the GUI the answer is no. Even if you could attach to the running process you would need to intercept the exception, but it is caught and sent to the GUI, not thrown from the application.
In theory, you could screen scrape the application. I don't know of any specific tools for doing this, but they may be out there.
Edit: I may have been wrong above, check out a post here where they get the stack from a running thread. You probably won't be able to capture the exception this way, but if you're lucky the stack trace will look very different when the program is operating normally compared to when an exception has been thrown.
Edit 2: I submitted a second, more accurate answer. See below.
Is the other program Java? Look at AspectJ, you may be able to hack something using it if you have control on the program startup.
Without ability to rebuild the app you are generally out of luck unless you do some extensive hacking. Here is one option I can think of.
Most likely the application replaces System.out and/or System.err with its own stream implementation. If that's the case you can try to locate the class for this stream and replace it with your own wrapper with the same name. You may rename original class using jarjar. In the wapper you can provide console output to detect the exception.
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'm working on a cross platform application in Java which currently works nicely on Windows, Linux and MacOS X. I'm trying to work out a nice way to do detection (and handling) of 'crashes'. Is there an easy, cross-platform way to detect 'crashes' in Java and to do something in response?
I guess by 'crashes' I mean uncaught exceptions. However the code does use some JNI so it'd be nice to be able to catch crashes from bad JNI code, but I have a feeling that's JVM specific.
For simple catch-all handling, you can use the following static method in Thread. From the Javadoc:
static void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh) Set the default handler invoked when a thread abruptly terminates due to an uncaught exception, and no other handler has been defined for that thread.
This is a very broad way to deal with errors or unchecked exceptions that may not be caught anywhere else.
Side-note: It's better if the code can catch, log and/or recover from exceptions closer to the source of the problem. I would reserve this kind of generalized crash handling for totally unrecoverable situations (i.e. subclasses of java.lang.Error). Try to avoid the possibility of a RuntimeException ever going completely uncaught, since it might be possible--and preferable--for the software to survive that.
For handling uncaught exceptions you can provide a new ThreadGroup which provides an implementation of ThreadGroup.uncaughtException(...). You can then catch any uncaught exceptions and handle them appropriately (e.g. send a crash log home).
I can't help you on the JNI front, there's probably a way using a native wrapper executable before calling the JVM, but that executable is going to need to know about all the possible JVMs it could be calling and how the indicate crashes and where crash logs are placed etc.
Not sure if this is what you needing, but you can also detect if an exception has occurred from within your native code. See http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp5234 for more info.