Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6583000

Attaching to local MQ broker process via jconsole causes broker JVM to seg fault

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 4.1, 6u2
    • Fix Version/s: 6u10
    • Component/s: tools
    • Subcomponent:
    • Resolved In Build:
      b03
    • CPU:
      sparc
    • OS:
      solaris_10

      Backports

        Description

        MQ or Message Queue is a component of Java Enterprise System. It is a JMS (Java Message Service) provider.

        The 'broker' is the server component part of MQ that listens for connections from clients (TCP by default) that want to send/receive messages.

        Anyhow, upon running the broker using JDK 1.6.0_02 and trying to connect to it using jconsole (jconsole_broker.gif attached), the broker process seg faults.

        I am running all this on a sparc machine:

        SunOS jmq-ultra7 5.10 Generic_118833-33 sun4u sparc SUNW,Ultra-60

        I am using the file based (and not the pkg based) install of 1.6.0_02 which I got from:

        /net/koori/onestop/jdk/1.6.0_02/latest/bundles/solaris-sparc
            jdk-6u2-solaris-sparc.sh

        /net/koori/onestop/jdk/1.6.0_02/latest/bundles/solaris-sparcv9
            jdk-6u2-solaris-sparcv9.sh

        I extracted/used both the sparc/sparcv9 bundles.

        I ran dbx on the core file and got:

        Reading java
        dbx: warning: NT_GWINDOWS section found. Possible stack overflow condition
        core file header read successfully
        Reading ld.so.1
        Reading libthread.so.1
        ...
        detected a multithreaded program
        t@1 (l@1) terminated by signal KILL (Killed)
        0xff2c158c: __lwp_wait+0x0008: bad opcode
        (.../dist/share/forte_dev,v6.2/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
        current thread: t@1
        =>[1] __lwp_wait(0x4, 0xffbfe264, 0xff362000, 0xff3ee980, 0x32380, 0xff3ee268), at 0xff2c158c
          [2] lwp_wait(0x2, 0xffbfe264, 0x0, 0xff3ee0f8, 0xff3f06e0, 0x0), at 0xff2b2e14
          [3] _thrp_join(0x2, 0x0, 0xffbfe328, 0x1, 0xffbfe264, 0xff2ecbc0), at 0xff2bcf90
          [4] thr_join(0x2, 0x0, 0xffbfe328, 0xffbfe3b8, 0x0, 0x0), at 0xff2bd0fc
          [5] ContinueInNewThread(0x124c0, 0x0, 0x20000, 0xffbfe3b8, 0xfffe7ccc, 0x0), at 0x18a04
          [6] main(0x18000, 0x2ac40, 0x0, 0x2b634, 0x44c, 0x2acac), at 0x12480

        To reproduce this problem, you need to:
         1. Obtain the latest build of MQ
         2. Install JDK 1.6.0_02
         3. Configure the broker to use JDK 1.6.0_02
         4. Start the broker
         5. Attach locally using jconsole

        To expedite the evaluation of this bug, I have setup a machine for steps (1-3) above.

        To see the vm seg fault:

        Log onto the machine:
         % rlogin jmq-ultra7.sfbay.sun.com

        I have placed all the relevant bundles/installs under:
          /export/jdk-crash

        cd to broker 'bin' directory to start it:
         % cd /export/jdk-crash/mq/4.1/imq/bin

        start the broker:
         % ./imqbrokerd -name <somename> -tty -Dimq.jmx.enabled=false
        You should see the broker starting up and eventually this line:
          [19/Jul/2007:14:57:20 PDT] [B1039]: Broker "<somename>@jmq-ultra7:7676" ready.

        In another window, log onto jmq-ultra7.sfbay.sun.com and set the DISPLAY variable to point to your desktop so you can run jconsole and view it on your desktop.
          % setenv DISPLAY <your machine>:0.0 (or whatever your display is)

        On your desktop, run 'xhost' to allow jconsole to display back to your desktop:
          % xhost +jmq-ultra7.sfbay.sun.com

        cd to where the JDK/jconsole is on jmq-ultra7.sfbay.sun.com:
          % cd /export/jdk-crash/jdk/sparcv9/jdk1.6.0_02/bin

        Run jconsole and attach to the running local broker java process.
          % ./jconsole

        --> the broker process should seg fault

        I've tried this on various sparcv9 machines - it's quite easy to reproduce this on jmq-ultra7.

        As my broker process cmdline shows, I've intentionally turned off our JMX management features to see if that has to do with any of this - but the VM still crashes.

        Please let me know if there is any info that I need/should provide here. I hate submitting bugs that don't have a simple Sample.java to test with but I cannot reproduce this on smaller apps.

        This is really in response to the MQ QA team filing bug:
         6581330 - (JDK1.6 x64 ) broker process will be terminated if connection failed using jconsole in cluster

        Instead of simply transfering the bug above to java/runtime I decided to try to narrow down the problem (no clustering needed, no high availability jars needed) and setup a machine to address this. Bug 6581330 indicates that this problem is seen also in JDKs 1.6.0 and 1.6.0_01. I decided to go with the latest/greatest JDK that is released.

        If you would like to install MQ 4.1 on your machine, you can copy this zip file:

          jmq-ultra7.sfbay.sun.com:/export/jdk_crash/MQ/mq4_1-Unix.zip

        to your test machine and unzip it there. To configure MQ to use a particulat JDK, you need to edit the file

         imq/etc/imqenv.conf

        or simply run the broker with the '-javahome' option eg

         % cd <directory where you unzip'd zip file>/imq/bin
         % ./imqbrokerd -name <yourname> -tty -Dimq.jmx.enabled=false -javahome /path_to_my_jdk

        Let me know if any setup help is needed here.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  ksrini Kumar Srinivasan
                  Reporter:
                  duke J. Duke (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: