3

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!
Community
  • 1
  • 1
scubbo
  • 4,969
  • 7
  • 40
  • 71

2 Answers2

2

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.

apangin
  • 92,924
  • 10
  • 193
  • 247
0

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]
Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136