Red Hat Bugzilla – Bug 997633
Adding com.sun.management.jmxremote system property to 32-bit JVM commandline crashes JVM
Last modified: 2013-11-21 06:14:13 EST
Description of problem: Adding '-Dcom.sun.management.jmxremote' to the java commandline crashes the 32bit JVM immediately. Version-Release number of selected component (if applicable): java-1.7.0-openjdk-1.7.0.25-2.4.1.0.el6.i686 How reproducible: Although you can reproduce it by executing a trivial compiled java program, the results are more easily reproducible by just executing the following command: java -Dcom.sun.management.jmxremote Alternatively, compile the following trivial class (JmxBug.java): public class JmxBug { public static void main(String[] args) { System.out.println("success"); } } And execute it: javac JmxBug.java && java -Dcom.sun.management.jmxremote JmxBug Using java-1.7.0-openjdk-1.7.0.25-2.3.10.4.el6_4.i686, the first scenario prints the java command usage. In the second scenario, the program executes, prints "success" and returns a 0 exit code. Using java-1.7.0-openjdk-1.7.0.25-2.4.1.0.el6.i686, in both scenarios the JVM exits immediately with a 1 exit code. Steps to Reproduce: 1. Add `-Dcom.sun.management.jmxremote` to the command line of any `java` command Actual results: The JVM crashes immediately with exit code 1. Expected results: The JVM to start with the default JMX agent enabled. Additional info: The bug is not present in the 64-bit package (java-1.7.0-openjdk-1.7.0.25-2.4.1.0.el6.x86_64).
For additional context, I noticed this bug after noticing ActiveMQ crashing on startup following the package upgrade to java-1.7.0-openjdk-1.7.0.25-2.4.1.0.el6.i686. Given the common nature of particular system property (enabling JMX), I feel this bug is high severity and would be very likely to break many popular java applications.
One more piece of context I forgot to mention: Tested on an x86_64 machine with all updates from http://qafiler.bos.redhat.com/redhat/nightly/latest-RHEL6.5/6.5/Server/x86_64/os/ and the i386 repo enabled from http://qafiler.bos.redhat.com/redhat/nightly/latest-RHEL6.5/6.5/Server/i386/os/ to pull in java-1.7.0-openjdk.i686 and java-1.7.0-openjdk-devel.i686 along with their dependencies.
I can not repdroduce on an i686 machine. Will test the i686 packages on x86_64 machine next.
I can reproduce this bug but only when using i686 packages on x86_64.
(In reply to Omair Majid from comment #4) > I can reproduce this bug but only when using i686 packages on x86_64. Omar, Does that mean this will be accepted as a bug to be fixed? Thanks for your effort.
An strace reveals that one of the last actions before the process exits is accessing `/usr/lib/libnss3.so`. This fails with a ENOENT. nss is listed as a Requires in the rpm but in a non-arch-specific style (`Requires: nss`). The x86_64 nss (/usr/lib64/libnss3.so) meets this rpm requirement, so yum-installing the i686 java-1.7.0-openjdk does not install the i686 nss. If you yum install the i686 nss (`yum install /usr/lib/libnss3.so`), the testcase works fine. The fix seems pretty straight-foward: -Requires: nss +Requires: nss%{?_isa} The following scratch build should fix the issue (once it completes): http://brewweb.devel.redhat.com/brew/taskinfo?taskID=6178834 Could you please test it out?
Omair, Confirmed that manually installing nss.i686 fixes the issue. Thanks for the scratch build; we'll mostly likely get around to testing it on Monday.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1611.html