Edited note: FYI, application extensively muti-threaded based desgined so may be something wrong in code. I need some time to trace code and get back in details.
thanks.
Related
See here for original question.
I'm writing a Java service, using Jetty for Webserving and SQLite for database storage. Source is available here.
I found that, although the service ran stably from my laptop, when deployed to an EC2 instance it would crash with no obvious error message in output somewhere between 1 hour and 2 days from starting up. I added some logging options to the startup call (-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=...), and got this crashlog.
This is the first time I've encountered such a file, and at first glance it doesn't seem very obvious which part of it refers to the actual error and which parts are just giving contextual information, so I'd really appreciate any good guides to understanding it. In particular, it looks like it's trying to interact with ZipFiles, which I don't use in my project.
This answer links to a blog which was -1'd in the answer comments
This answer links to some Oracle documentation, which I would normally be overjoyed at, but it appears to be a general debugging guide - can't see anything in there about hs_err files (though that may become clear on further reading)
This result from Google claims that "whatever Java code you execute, JVM should never crash. If it does, it is just a JVM bug. So try to log a defect with Sun with all details and hopefully they will look into that.", which sounds pretty absolutist - I think it's highly unlikely that my little toy project has uncovered a JVM bug!
Crashes in Java_java_util_zip_ZipFile_getEntry are most often caused by concurrent access to .zip files, e.g. a file is overwritten while an open instance exists.
See JDK-8042197, JDK-8031691 for details.
BTW, as to original question, here is a presentation on JVM crash dump analysis.
Looking at the crashlog, it appears that something you were unpacking (jar file or zip file) resulted in a JVM crash.
If this occurs during startup, try adding this to your JVM command line to see which file it was possibly working on.
java -verbose:class [more command line]
I am in a very very upset situation. My program worked 100% fine when it is in netbeans, but when I build it it has some issues. That is, in my program, there is an one interface and 10 implementation classes. Program calls correct correct implementation class based on how the user save the file (eg: if user save it as game.yellow, it will call "YellowImpl.java", if saved as game.red, then "RedImpl.java" likewise).
But when it is built, it is calling everything fine, instead YellowImpl!! Which means, if the user saves it as game.red, it will call "RedImpl" correctly and same to all other implementations instead YellowImpl. When the user save the file as game.yellow, the program do nothing!!! But this is not happening when it is inside the netbeans! I tried clean and build too, still not good! What is causing this ? Please help!
However, I am unable to provide the code, because it has lot of codings
PS: I am using some libs too
It's difficult to understand exactly what issue you are having with your explaination and no code. However I assume you are having issue with implementation naming conventions.
Perhaps the below link can help.
Java Interfaces/Implementation naming convention
I am agree with #Rhys: it is hard to understand what happens in your application. Just let me give you an advice: do not think (even for 1 second) that there is a bug in java compiler, JVM etc. It is definitely your bug.
How to find it? I suggest you to use remote debugging.
Run your application outside IDE (NetBeans in your case) with enabled remote debugger, connect to it with net beans and debug your application. I believe you will fined the problem within minutes.
How to enable remote debugging? Add the following long string to your java execution command line:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
If something happens in very beginning of your program execution use suspend=y.
Now connect to this application from NetBeans. It is simple, just configure it to port 8000 according to the configuration of your application.
That's it. Good luck.
Thanks a lot for the replies guys. However, I managed to find the issue. That was a simple, capital case!! I have a package called "kolor" and all the implementations are inside that. In my "YelloImpl" class, I have mentioned the package as "Kolor" (Note that "K" is capital). It was fine in netbeans, but outside it wasn't. After clearing this out, everything went fine. Thanks all for the replies again.
Is it possible for GWT to give the stack trace for the original Java code after a crash, as opposed to the JS stack trace?
I'm using Chrome 17.
It depends on what browser you're using at the time of the crash, but GWT has built functinality for emulating Java stack traces. Make sure you are compiling and implementing the symbolmap files in your war directory with your cache js files.
Another option is to compile with the output style set to "Detailed", and then looking at the raw javascript in any standard browser javascript console will point you to the right place in your Java code, as nearly every line in the javascript refers to a fully-qualified class name and method.
It is possible to get the original stacktrace but you have to perform Deobfuscation
We had similar issue. It works fine, and with latest GWT version even shows line numbers.
Notice to my comments for Thomas Broyer answer.
Recently two of our clients have reported problems with our applets. Looking at the java plugin console it is full of ClassNotFoundException so none of our code is executed.
I've been able to reproduce the stack trace using a virtual pc image with 0 free space on disk, but the problem goes away as I restore some disk space, and the users tell me that their disk is not full; they are able to create new files.
Our applet requires java 6, and the problem has appeared with updates 1, 10 and 14 of the jre. We have also tried different browsers (IE and Firefox), clearing the browser and java caches, ...
How can I debug or trace what is the jvm doing to load our applet?
I suppose that the problem lies on some security directive on windows so I'm using Sysinternal's Process Monitor to log the activity but I don't really know where to look at.
The Java cache is most likely messed up. Open Java in the Control Panel and get rid of all temporary files to see if it goes away.
Logging in the Java Console for loading applets can be enabled which helps quite alot (even if the plugin is extremely cryptic). See http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html
I've been looking at the plugin source from the JDK and I've found that there is additional debug info available in the logs setting the environment variable JPI_PLUGIN2_DEBUG.
Unfortunately I still only see ClassNotFound exceptions.
I've found a piece of the plugin code that swallows all exceptions, so maybe my users problem is there...
had similar problems a while ago. In our case, the problem seems to be how the applet tag is set up on the web page. If it is in a wrong order or contains the codebase attribute, it fails with 6u10+. This works for us:
<applet name="DMGANTT" archive="DMGantt.zip" code="dm.applet.DMGanttApplet"
width='100%' height='100%' mayscript="mayscript">
We had a similar problem with one of our clients. We discovered that it was a strange bug in some versions of Java related to proxy configuration on the client. See this article for the details
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723715
Also, our applet failed with new versions for a different reason.
Now, in similar cases I ask them to check javatester.org, so that I can see if applets (in general) load OK in their browser. If that page loads OK, its a problem on our applet (or page). Else it's a problem in their configuration. I help them anyway but it's easier to debug.
I've been learning Java for about a month now, and not very familiar with a client/server situation like this one.
Basically I ran into a situation where our client java software (GUI) displayed a nullpointerexception popup but no stack trace on the client side. Someone had to go check the server side for the stack trace.
My question is, shouldn't the client side receive this precious information as well? Are situations like that ok, the rationale being one only needs one copy of the stack trace?
Not really. It is not recommended to show the way your app works from behind to the client. Mainly for security reasons. Your stacktrace shows all the objects being called, methods and if compiled with debug info, even lines. That's too much information for the client, it is ok to have it on the server.
This among SQL injection, Cross side script and others that I cannot remember, improper exception handling is a security vulnerability.
EDIT:
Here are other vulnerabilities ( although I don't see this one listed :( )
http://en.wikipedia.org/wiki/Vulnerability_(computing)
The client only needs to know hat it needs to know.
In alot of cases it perfectly fine to not show any stacktraces on your client.
Your users should get clear error messages but dont care about a stacktrace.
For debugging purposes a stacktrace is generally lost anyway, application gives errors, users restart it and gone is any excpetion, so if you need to know the errors use a logging framework.