#274 SIGNAL 11 without additional infos


Hi guys,

we're facing a strange problem in our application using wrapper since we've deployed a tiny code change (no JNI). The app is running on RHEL 5.4, JDK 1.6.0_18, wrapper 3.3.3. After a while the application crashes due to a signal 11 without any additional information. We've tried everything to get some more information like a threaddump or heapdump out of the VM, but without any success. The only info we're getting is this:

STATUS | wrapper | main | 2010/03/24 00:10:24.450 | JVM received a signal UNKNOWN (11).
STATUS | wrapper | main | 2010/03/24 00:10:24.450 | JVM process is gone.
ERROR | wrapper | main | 2010/03/24 00:10:24.450 | JVM exited unexpectedly.

Since there is no vm error logged at all I'm wondering whether this might be an issue with the wrapper, is there any similar issues known or do you see a possibility to get at least some more information about where the crash occurs?

Thanks in advance,



  • Christian Mueller


    Signal 11 is the segmentation violation signal - SIGSEGV.

    I assume that this is happening somewhere in the JNI code. However seeing just the small output I can not anticipate where exactly.

    Can you post the full log file or better switch to wrapper.logfile.loglevel=DEBUG and send this logfile?
    Could you also please explain what tiny code change you made?

    Best Regards,

  • Christian Mueller


    usually the jvm writes a dump file out when it detects a segv.
    please check at %WRAPPER_HOME%/bin/ for a hs_err_pid***.log file...


  • Christoph Kipp

    Christoph Kipp - 2010-03-25

    Hi Christian,

    first thanks for your quick response! I'll try to answer most of your questions:

    - Our application is an ecommerce app running inside tomcat. The code change is just some additional webservice methods. We're not using JNI at all in our application.

    - The weird thing is I don't get any information apart from the posted one out of the VM, no dump, not even an error message. I've already tried various things to shade some light on the actual error like adding JVM options -XX:+ShowMessageBoxOnError and -XX:ErrorFile without getting any infos. That's why I suspect the wrapper might be part of the problem.

    - I'll try to set the wrapper loglevel to debug and then post the log infos, but unfortunately I can't test this right away now.

    - What we've (unsuccesfully) tried so far to get rid of the problem:

    - Upgrade RHEL 5.3 to RHEL 5.4
    - Upgrade JAVA from 1.6.0_14 to 1.6.0_18
    - Switch off hotspot compilation (-Xint)
    - Make sure the wrapper uses the 64bit libs

    The last thing to try that came to my mind is a downgrade to JDK 1.5, but then I'm running out of options...

    Best regards,


  • Leif Mortenson

    Leif Mortenson - 2010-03-25

    I am not aware of any crash problems in version 3.3.3 of the Wrapper. There was one problem that was fixed in 3.3.0.

    It sounds like this is easy to reproduce, which is good news. To help you rule out the Wrapper, please do the following.

    1) Rename your lib/libwrapper.so file and retest. This will remove all of the Wrapper's native code from the JNI process. Some functions will be disabled, but most of the Wrapper will continue to function correctly.

    2) If that still shows the crash, next try removing the wrapper binary from the equation. Edit your Wrapper.conf file by adding the wrapper.java.command.loglevel=INFO property and rerunning. This will cause the full Java command line to be written to the wrapper.log. Copy that into a new shell script and delete only the -Dwrapper.key=NNN argument. You will now be able to run the JVM using that script without the wrapper binary.
    Does this still show the problem?
    This number 2 is just a suggestion to help you rule out the Wrapper. I do not think this will make any difference as the Wrapper is launching the JVM as an independent process.

    How long after the JVM is launched is it crashing? What is being done when it crashes? Or is it random?


  • Christoph Kipp

    Christoph Kipp - 2010-03-25

    Hi Leif,

    thanks very much for the input, I'll try out your suggestions tonight. Actually the appearance of the problem seems to be load-related, if the app is under load it takes only seconds until it occurs, in other cases more than an hour. That's why I thought it might be a problem with hotspot compilation. The problem occurs without the webservices being used, so I guess the code changes are somehow related but rather indirectly causing the problem.

    I'll kepp you posted once I tried your suggestions.



  • Christoph Kipp

    Christoph Kipp - 2010-04-06

    Hi guys,

    after fiddling around with lots of JVM / OS / Wrapper combinations for the past weeks we've gained some insight and are probably close to a solution. The problem was reproducible with every combination of JVM (1.6.0_14 to 1.6.0_19), OS (RHEL 5.3, RHEL 5.4, SLES 10) and also inside a VMWare environment.

    We ran the whole application inside GDB without wrapper which brought us forward: It seems like the JVM is causing a segfault (SIG 11) but handles this itself, after we caught the segfault, the JVM was still running, this explains why we've been getting no coredump out of the JVM whatever we tried. In combination with the wrapper the behaviour seems to be the same, however the wrapper catches the segfault and then kills the JVM though it is still operational.

    We will try to reproduce this behaviour in a test environment, now that we also know where the error happens, I would consider this an error in the JVM, but I guess one just notices it when using the wrapper or a debugger. Do you think there is a possibility to make the wrapper not kill the JVM but rather produce log output and a threaddump when it catches SIG 11?




Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks