6

I'm trying to run jetty inside a Centos 5.7 vagrant box (it runs fine on "real" computers; tested with centos and linux mint). This is the header error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002abb2551a8b1, pid=4299, tid=1105414464
#
# JRE version: 6.0_37-b06
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.12-b01 mixed mode linux-amd64 )
# Problematic frame:
# V  [libjvm.so+0x87a8b1]  YieldingFlexibleWorkGang::start_task(YieldingFlexibleGangTask*)+0x11
#
# An error report file with more information is saved as:
# /usr/local/jetty-7.6.7/bin/hs_err_pid4299.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted

I've pasted the log here: https://gist.github.com/favrik/4067152

I'm trying to get some hints. :) Already searched google and the bug database at http://bugs.sun.com/.

Thanks!

K3---rnc
  • 6,717
  • 3
  • 31
  • 46
Favio
  • 1,009
  • 1
  • 8
  • 19
  • 1
    Are the JVM versions the same? Do you get this error consistently? – hsanders Nov 13 '12 at 17:30
  • Yeah, everytime I run the command I get the same error, have tried with different memory settings too. JVM versions are the same, in fact the vagrant box mirrors the "real" Centos system. However, java is installed slightly different (different path), not sure if this can cause a fatal error. – Favio Nov 13 '12 at 17:55
  • 1
    Maybe try a different version of JVM? With a lot of virtualization environments, even if the distro is the same the kernel is slightly different to run in that specific hypervisor. If you can't change the kernel, maybe try changing the JVM because that's probably easier to change. – hsanders Nov 13 '12 at 19:30
  • 1
    I did try with different JVM versions but still got the same fatal error. Tried with the option mentioned by dan and now is not crashing. Thanks! – Favio Nov 13 '12 at 20:20

1 Answers1

5

If you are able to reproduce this easily, you should configure your system to create a core dump.

Using ulimit -c unlimited will enable your system to produce such a dump on the next SIGSEGV event. Once the core dump file will be created you will be able to examine it, using gdb.

See Determining Where the Crash Occurred for details on what options to use to determine the cause.

dan
  • 13,132
  • 3
  • 38
  • 49
  • 1
    @Favio From your stack traces it seems something related to the Concurrent Mark Sweep Collector. Just to test you should try `-XX:+UseSerialGC` to see if it makes any difference. – dan Nov 13 '12 at 19:59
  • with that option it doesn't crash anymore! :D I have no idea why that would crash the jvm though, but it's good enough that I can just use that option since this is a dev vagrant box and not production. Thanks! – Favio Nov 13 '12 at 20:17
  • @Favio You're welcome. You should open a bug and post the `gdb` output, since this should not happen. – dan Nov 13 '12 at 20:19
  • 1
    As dan answered, what fixed this problem for me was to use: -XX:+UseSerialGC – dessalines Mar 04 '14 at 15:16
  • How and where to use -XX:+UseSerialGC ? – Awaish Kumar Apr 01 '21 at 22:32
  • 1
    @AwaishKumar `-XX:+UseSerialGC` are JVM command line arguments. Just append the option to `JAVA_OPTIONS` variable in your `jetty.sh` file. – dan Apr 02 '21 at 05:00