4 Replies Latest reply: Nov 18, 2011 9:51 AM by Andrew Dinn RSS

java.lang.ClassFormatError when unloading rules

Den Galley Newbie

I downloaded version 1.6.0 of byteman and tried to follow some of the steps from the byteman tutorial at http://community.jboss.org/wiki/ABytemanTutorial  but ran into a couple of issues

 

1. I had some weblogic server processes running on our linux machines and I wanted to start an agent using the bmsubmit script. I ran the bminstall script with the pid of the weblogic server as the port:

     ./bminstall.sh 8249 ( 8249 is the pid of the weblogic server process)

 

    I expected this command to start a agent listener but the command would just sit there and do nothing. I checked the weblogic server logs and there was nothing in it. In the tutorial, it was stated that bminstall might work with JRockit JVM but apparently it is not working.

 

2. With no success using bminstall, I had to fall back to the hard way and add -javaagent option to my weblogic server and bounce it.

  -javaagent:$BYTEMAN_HOME/lib/byteman.jar=listener:true,port:8904

   ( I noticed that if port option is used with out setting the listener option to true, it was not starting a listener. Documentation says that setting a value to the port implicitly sets the listener to true but I didn't see that happen)

 

  Using netstat command, I verified that the listener was started.

 

  I then wrote a simple byteman script that throws an exception in one of the methods and submitted using the bmsubmit command:

 

bmsubmit.sh -p 8904 -l throw.btm

 

  This command worked fine. My code starting throwing exceptions at the specified location in the btm.

 

  Next, I attempted to unload the files using -u option:

   bmsubmit.sh -p 8904 -u throw.btm

 

  This command caused the server process to throw an error which was captured in the weblogic logs:

   

   exception in thread "Thread-0" java.lang.ClassFormatError

        at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

        at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:124)

        at org.jboss.byteman.agent.Retransformer.removeScripts(Retransformer.java:292)

        at org.jboss.byteman.agent.TransformListener.handleScripts(TransformListener.java:335)

        at org.jboss.byteman.agent.TransformListener.deleteScripts(TransformListener.java:290)

        at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:215)

        at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:146)

 

   I would appreciate if you can look into this issue. I am very excited about using byteman for putting our code through various exception scenarios. It would a great tool for such kind of testing.

 

   My Platform details:

     OS: Redhat AS 4. 5 ( Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

     JVM : Jrockit JVM 1.6.0.5

              java version "1.6.0_05"

             Java(TM) SE Runtime Environment (build 1.6.0_05-b13)

             BEA JRockit(R) (build R27.6.0-50_o-100423-1.6.0_05-20080626-2104-linux-ia32, compiled mode)

     Byteman Version: 1.6.0

 

 

Thanks,

DG

  • 1. Re: java.lang.ClassFormatError when unloading rules
    Andrew Dinn Master

    Hi Den,

     

    Thanks for posting this report.

     

    Den Galley wrote:

     

    I downloaded version 1.6.0 of byteman and tried to follow some of the steps from the byteman tutorial at http://community.jboss.org/wiki/ABytemanTutorial  but ran into a couple of issues

     

    1. I had some weblogic server processes running on our linux machines and I wanted to start an agent using the bmsubmit script. I ran the bminstall script with the pid of the weblogic server as the port:

         ./bminstall.sh 8249 ( 8249 is the pid of the weblogic server process)

     

        I expected this command to start a agent listener but the command would just sit there and do nothing. I checked the weblogic server logs and there was nothing in it. In the tutorial, it was stated that bminstall might work with JRockit JVM but apparently it is not working.

     

    I have jrockit 1.6.0_20-b02 installed on my machine and I just used it to run JBoss AS7. When I ran bminstall.sh it sucessfully loadd the byteman agent into the JVM

     

    [adinn@localhost byteman]$ jboss start

    starting standalone AS7

    [adinn@localhost byteman]$ bmsubmit.sh

    Failed to process request: java.net.ConnectException: Connection refused

    java.net.ConnectException: Connection refused

        at java.net.PlainSocketImpl.socketConnect(Native Method)

        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)

        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)

        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)

        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)

        at java.net.Socket.connect(Socket.java:529)

        at java.net.Socket.connect(Socket.java:478)

        at java.net.Socket.<init>(Socket.java:375)

        at java.net.Socket.<init>(Socket.java:189)

        at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)

        at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)

        at org.jboss.byteman.agent.submit.Submit.listAllRules(Submit.java:174)

        at org.jboss.byteman.agent.submit.Submit.main(Submit.java:1037)

    [adinn@localhost byteman]$ jps -l

    7380 sun.tools.jps.Jps

    7315 /home/adinn/jboss/jbossas/git/jboss-as/build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/jboss-modules.jar

    3139 com.intellij.idea.Main

    [adinn@localhost byteman]$ bminstall.sh 7315

    [adinn@localhost byteman]$ bmsubmit.sh

    no rules installed

     

    [adinn@localhost byteman]$

     

    The install program does not print out a message but you can see it has worked -- before the install bmsubmit failed ot connect to an agent. After the install it finds an agent and no rules loaded. So, this may be to do with you using a different version of JRockit. Can you try a different version such as the one I used?

     

     

    Den Galley wrote:

     

    2. With no success using bminstall, I had to fall back to the hard way and add -javaagent option to my weblogic server and bounce it.

      -javaagent:$BYTEMAN_HOME/lib/byteman.jar=listener:true,port:8904

       ( I noticed that if port option is used with out setting the listener option to true, it was not starting a listener. Documentation says that setting a value to the port implicitly sets the listener to true but I didn't see that happen)

     

    Yes, that's what is supposed to happen but I looked at the code and it does not do what is expected. Here is the JIRA

     

    https://issues.jboss.org/browse/BYTEMAN-178

     

    Den Galley wrote:

     

      I then wrote a simple byteman script that throws an exception in one of the methods and submitted using the bmsubmit command:

     

    bmsubmit.sh -p 8904 -l throw.btm

     

      This command worked fine. My code starting throwing exceptions at the specified location in the btm.

     

      Next, I attempted to unload the files using -u option:

       bmsubmit.sh -p 8904 -u throw.btm

     

      This command caused the server process to throw an error which was captured in the weblogic logs:

       

       exception in thread "Thread-0" java.lang.ClassFormatError

            at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

            at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:124)

            at org.jboss.byteman.agent.Retransformer.removeScripts(Retransformer.java:292)

            at org.jboss.byteman.agent.TransformListener.handleScripts(TransformListener.java:335)

            at org.jboss.byteman.agent.TransformListener.deleteScripts(TransformListener.java:290)

            at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:215)

            at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:146)

     

       I would appreciate if you can look into this issue. I am very excited about using byteman for putting our code through various exception scenarios. It would a great tool for such kind of testing.

     

       My Platform details:

         OS: Redhat AS 4. 5 ( Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

         JVM : Jrockit JVM 1.6.0.5

                  java version "1.6.0_05"

                 Java(TM) SE Runtime Environment (build 1.6.0_05-b13)

                 BEA JRockit(R) (build R27.6.0-50_o-100423-1.6.0_05-20080626-2104-linux-ia32, compiled mode)

         Byteman Version: 1.6.0

     

    Hmm, that's interesting. I tried laoding the following rule and got a verify error during the load

     

    [adinn@localhost byteman]$ cat foo.btm

    RULE foo

    CLASS FileSystemDeploymentService

    METHOD scan

    AT ENTRY

    IF TRUE

    DO traceln("scan")

    ENDRULE

    [adinn@localhost byteman]$ bmsubmit foo.btm

    install rule foo

    VerifyError during retransformation : some rules may not have been correctly injected or uninjected!

    java.lang.VerifyError

    at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

    at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:124)

    at org.jboss.byteman.agent.Retransformer.installScript(Retransformer.java:136)

    at org.jboss.byteman.agent.TransformListener.handleScripts(TransformListener.java:337)

    at org.jboss.byteman.agent.TransformListener.loadScripts(TransformListener.java:260)

    at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:213)

    at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:146)

     

    When I use Sun's JDK or OpenJDK this doesn't happen. I'll start dumping bytecode and see if there is something in the code the verifier does not like. Interestingly, I saw a similar error to yours when I first ran Byteman on Sun's JDK7 because the verifier uses different rules to JDK6. I'll get back to you when I find out more.

  • 2. Re: java.lang.ClassFormatError when unloading rules
    Andrew Dinn Master

    Hi Den,

     

    The verify error I got last time was a red herring. This morning I did manage successfully to load and unload my rule using JRockit 1.6.0_20-b02 (the reason I got the verify error before was because I was using JBoss AS7 and I did not configure the module loader to ensure that Byteman classes were visible to all loaders (you need to start AS7 with -Djboss.modules.system.pkgs=org.jboss.byteman). Here's what I did (n.b. I am starting jboss using my own private start script)

     

    [adinn@localhost byteman]$ export JBOSS_OPTS="$JBOSS_OPTS -Djboss.modules.system.pkgs=org.jboss.byteman"

    [adinn@localhost byteman]$ jboss start -debug -watch

    starting standalone AS7

    =========================================================================

     

      JBoss Bootstrap Environment

     

      JBOSS_HOME: /home/adinn/jboss/jbossas/git/jboss-as/build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT

     

      JAVA: /home/adinn/Download/jrockit/jrmc-4.0.1-1.6.0/bin/java

     

      JAVA_OPTS: -server -Xms600M -Xmx600M -XX:MaxPermSize=128m -Djboss.modules.system.pkgs=org.jboss.byteman -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

     

    =========================================================================

     

    [WARN ][jrockit] MaxPermSize=128m ignored: Not a valid option for JRockit

    Listening for transport dt_socket at address: 5005

    Listening for transport dt_socket at address: 5005

    11:42:01,784 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA

    11:42:02,033 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA

    11:42:02,094 INFO  [org.jboss.as] JBoss AS 7.1.0.Alpha1-SNAPSHOT "Lightning" starting

    . . .

     

    Ok, that's jboss started now I install the agent and then submit and unsubmit the rule

     

     

    [adinn@localhost byteman]$ bminstall.sh -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.dump.generated.classes -Dorg.jboss.byteman.dump.generated.classes.directory=dump 6561

    [adinn@localhost byteman]$ bmsubmit.sh foo.btm

    install rule foo

     

    [adinn@localhost byteman]$ bmsubmit.sh

    # File foo.btm line 5

    RULE foo

    CLASS FileSystemDeploymentService

    METHOD scan

    AT ENTRY

    IF TRUE

    DO traceln("scan")

    ENDRULE

    Transformed in:

    loader: ModuleClassLoader for Module "org.jboss.as.deployment-scanner:main" from local module loader @2cba5bdb (roots: /home/adinn/jboss/jbossas/git/jboss-as/build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules)

    trigger method: org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan() void

    compiled successfully

     

    [adinn@localhost byteman]$ bmsubmit.sh -u

    uninstall RULE foo


    [adinn@localhost byteman]$

     

    During this install/load/unload I saw the following in the AS7 output

     

    . . .

    11:42:42,055 INFO  [stdout] (Attach Listener) Setting org.jboss.byteman.verbose=

    11:42:42,055 INFO  [stdout] (Attach Listener) Setting org.jboss.byteman.dump.generated.classes=

    11:42:42,055 INFO  [stdout] (Attach Listener) Setting org.jboss.byteman.dump.generated.classes.directory=dump

    11:42:42,083 INFO  [stdout] (Attach Listener) TransformListener() : accepting requests on localhost:9091

    11:42:45,740 INFO  [stdout] (Thread-17) TransformListener() : handling connection on port 9091

    11:42:45,777 INFO  [stdout] (Thread-17) retransforming org.jboss.as.server.deployment.scanner.FileSystemDeploymentService

    11:42:45,856 INFO  [stdout] (Thread-17) org.jboss.byteman.agent.Transformer : possible trigger for rule foo in class org.jboss.as.server.deployment.scanner.FileSystemDeploymentService

    11:42:45,902 INFO  [stdout] (Thread-17) RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan() void for rule foo

    11:42:45,940 INFO  [stdout] (Thread-17) org.jboss.byteman.agent.Transformer : inserted trigger for foo in class org.jboss.as.server.deployment.scanner.FileSystemDeploymentService

    11:42:45,960 INFO  [stdout] (Thread-17) org.jboss.byteman.agent.Transformer : Saving transformed bytes to dump/org/jboss/as/server/deployment/scanner/FileSystemDeploymentService.class

    11:42:48,807 INFO  [stdout] (DeploymentScanner-threads - 2) Rule.execute called for foo_0

    11:42:48,818 INFO  [stdout] (DeploymentScanner-threads - 2) HelperManager.install for helper classorg.jboss.byteman.rule.helper.Helper

    11:42:48,819 INFO  [stdout] (DeploymentScanner-threads - 2) calling activated() for helper classorg.jboss.byteman.rule.helper.Helper

    11:42:48,819 INFO  [stdout] (DeploymentScanner-threads - 2) Default helper activated

    11:42:48,819 INFO  [stdout] (DeploymentScanner-threads - 2) calling installed(foo) for helper classorg.jboss.byteman.rule.helper.Helper

    11:42:48,820 INFO  [stdout] (DeploymentScanner-threads - 2) Installed rule using default helper : foo

    11:42:48,821 INFO  [stdout] (DeploymentScanner-threads - 2) foo execute

    11:42:48,821 INFO  [stdout] (DeploymentScanner-threads - 2) scan

    11:42:53,834 INFO  [stdout] (DeploymentScanner-threads - 2) Rule.execute called for foo_0

    11:42:53,834 INFO  [stdout] (DeploymentScanner-threads - 2) foo execute

    11:42:53,835 INFO  [stdout] (DeploymentScanner-threads - 2) scan

    11:42:58,840 INFO  [stdout] (DeploymentScanner-threads - 2) Rule.execute called for foo_0

    11:42:58,841 INFO  [stdout] (DeploymentScanner-threads - 2) foo execute

    11:42:58,842 INFO  [stdout] (DeploymentScanner-threads - 2) scan

    11:43:03,852 INFO  [stdout] (DeploymentScanner-threads - 1) Rule.execute called for foo_0

    11:43:03,855 INFO  [stdout] (DeploymentScanner-threads - 1) foo execute

    11:43:03,858 INFO  [stdout] (DeploymentScanner-threads - 1) scan

    11:43:08,868 INFO  [stdout] (DeploymentScanner-threads - 1) Rule.execute called for foo_0

    11:43:08,869 INFO  [stdout] (DeploymentScanner-threads - 1) foo execute

    11:43:08,878 INFO  [stdout] (DeploymentScanner-threads - 1) scan

    11:43:10,315 INFO  [stdout] (Thread-17) TransformListener() : handling connection on port 9091

    11:43:13,896 INFO  [stdout] (DeploymentScanner-threads - 2) Rule.execute called for foo_0

    11:43:13,897 INFO  [stdout] (DeploymentScanner-threads - 2) foo execute

    11:43:13,898 INFO  [stdout] (DeploymentScanner-threads - 2) scan

    11:43:15,556 INFO  [stdout] (Thread-17) TransformListener() : handling connection on port 9091

    11:43:15,574 INFO  [stdout] (Thread-17) retransforming org.jboss.as.server.deployment.scanner.FileSystemDeploymentService

    11:43:15,595 INFO  [stdout] (Thread-17) HelperManager.uninstall for helper classorg.jboss.byteman.rule.helper.Helper

    11:43:15,596 INFO  [stdout] (Thread-17) calling uninstalled(foo) for helper classorg.jboss.byteman.rule.helper.Helper

    11:43:15,596 INFO  [stdout] (Thread-17) Uninstalled rule using default helper : foo

    11:43:15,596 INFO  [stdout] (Thread-17) calling deactivated() for helper classorg.jboss.byteman.rule.helper.Helper

    11:43:15,596 INFO  [stdout] (Thread-17) Default helper deactivated

    . . .

     

     

    So, you can see the agent being installed, the code injected (and the bytecode eing dumped to a file) the rule firing and then the rule bieng uninstalled and the rule no longer firing. I decompiled the bytecode and it doesn't look like their is anythign wrong with it.

     

    One thing that might be revealing would be for you start up the agent with your JRockit release using -javaagent on the command line and also setting the -D options I passsed to bminstall

     

    -Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.dump.generated.classes -Dorg.jboss.byteman.dump.generated.classes.directory=dump

     

    You will need to create a directory called dump in the working directory of your program.

     

    The verbose trace might at least show something about what is happening. Also, when the bytecode is transformed it will be dumped to a class file below directory dump. You can decompile this with javap -c to look at the bytecode and see what might be causing the verify error. I'd be happy to try to check it for you but, of course, I understand that you might not be able to share this code with me. Let me know what you can find out from trying this, also whether you can get Byteman to work on a different version of JRockit.

  • 3. Re: java.lang.ClassFormatError when unloading rules
    Den Galley Newbie

    Andrew,

         Per your suggestion, I restarted my weblogic server after adding the byteman -D options(-Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.dump.generated.classes -Dorg.jboss.byteman.dump.generated.classes.directory=/var/tmp/dump). Once the server came back up, I used bminstall.sh to load the rule. Here is the output from the weblogic logs after the rule is loaded:

     

    retransforming HubServicesDb

    org.jboss.byteman.agent.Transformer : possible trigger for rule simulate excp in HubServicesDb

    RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into HubServicesDb.compileSearch(IdAccess) java.util.List for rule simulate excp

    RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into HubServicesDb.compileSearchSearch, SearchFilter) java.util.List for rule simulate excp

    org.jboss.byteman.agent.Transformer : inserted trigger for simulate excp in class HubServicesDb

    org.jboss.byteman.agent.Transformer : Saving transformed bytes to /var/tmp/dump/HubServicesDb.class

     

    I then tried uninstalling the rule using the -u option but it failed like before:

    TransformListener() : handling connection on port 8904

    retransforming HubServicesDb

    Exception in thread "Thread-0" java.lang.ClassFormatError

            at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

            at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:124)

            at org.jboss.byteman.agent.Retransformer.removeScripts(Retransformer.java:292)

            at org.jboss.byteman.agent.TransformListener.handleScripts(TransformListener.java:335)

            at org.jboss.byteman.agent.TransformListener.deleteScripts(TransformListener.java:290)

            at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:215)

            at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:146)

     

    I looked at the disassembled bytecode in the /var/tmp directory. I am not very sure what to look for here. I did see the bytecode had calls in there for the byteman methods. Here is one of them:

      

    12:  invokestatic    #382; //Method org/jboss/byteman/rule/Rule.execute:(Ljava/lang/String;Ljava/lang/Object;[Ljava/lang/Object;)V

     

     

    Unfortunately, I can't use a different version of Jrockit JVM since 1.6.0.5 is our standard version. For me to be able to use byteman, I would need this issues resolved. Please let me know if there is anything else I should be trying to get more clues as to what is happening here.

     

    Also, here is the rule I am using for this test:

     

    RULE simulate excp

    CLASS HubServicesDb

    METHOD compileSearch

    AT ENTRY

    IF true

    DO

      traceln("Throwing an exception" + $1 ) ;

      throw new RuntimeException("Test exception");

    ENDRULE

     

    The class HubServicesDb is part of a package but since the package name contains some confidential information, I have deleted it from this post

     

     

    Thanks,

    DG

  • 4. Re: java.lang.ClassFormatError when unloading rules
    Andrew Dinn Master

    Hi Den,

     

    Thanks very much for pursuing this further.

    Den Galley wrote:

     

    Andrew,

         Per your suggestion, I restarted my weblogic server after adding the byteman -D options(-Dorg.jboss.byteman.verbose -Dorg.jboss.byteman.dump.generated.classes -Dorg.jboss.byteman.dump.generated.classes.directory=/var/tmp/dump). Once the server came back up, I used bminstall.sh to load the rule. Here is the output from the weblogic logs after the rule is loaded:

     

    retransforming HubServicesDb

    org.jboss.byteman.agent.Transformer : possible trigger for rule simulate excp in HubServicesDb

    RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into HubServicesDb.compileSearch(IdAccess) java.util.List for rule simulate excp

    RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into HubServicesDb.compileSearchSearch, SearchFilter) java.util.List for rule simulate excp

    org.jboss.byteman.agent.Transformer : inserted trigger for simulate excp in class HubServicesDb

    org.jboss.byteman.agent.Transformer : Saving transformed bytes to /var/tmp/dump/HubServicesDb.class

     

    Ok, so it looks for sure that the rule has been injected into HubServicesDb.compileSearch without a verify error. So this seems to indicate that the transformaion is valid. Normally, if there is an error in the generated btecode then the VM throws an exception when the transformer returns, refusing to install the changed byecode and reverting to the original. This would happen immediately after the save message so the lack of any exception trace is good. Did the injected bytecode actually execute and throw the expeced exception?

     

    Den Galley wrote:

     

    I then tried uninstalling the rule using the -u option but it failed like before:

    TransformListener() : handling connection on port 8904

    retransforming HubServicesDb

    Exception in thread "Thread-0" java.lang.ClassFormatError

            at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)

            at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:124)

            at org.jboss.byteman.agent.Retransformer.removeScripts(Retransformer.java:292)

            at org.jboss.byteman.agent.TransformListener.handleScripts(TransformListener.java:335)

            at org.jboss.byteman.agent.TransformListener.deleteScripts(TransformListener.java:290)

            at org.jboss.byteman.agent.TransformListener.handleConnection(TransformListener.java:215)

            at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:146)

     

    I looked at the disassembled bytecode in the /var/tmp directory. I am not very sure what to look for here. I did see the bytecode had calls in there for the byteman methods. Here is one of them:

      

    12:  invokestatic    #382; //Method org/jboss/byteman/rule/Rule.execute:(Ljava/lang/String;Ljava/lang/Object;[Ljava/lang/Object;)V

     

    Yes, that is one part of the transformation process. This call is injected at the injection point to hand over control to the rule execution engine.

     

    If you don't really want to know the nitty-gritty details just squint or shut your eyes untl you reach the next paragraph. In case you do here is the background context explaining this call. The call is preceded by some code which bundles up the method local state referenced by the rule code (method params, local vars and special vars like $! etc). In your case you only reference $1 so this requires loading the first method parameter into an  Object array created with length 1. Then there are insructions which stack the 3 parameters to this call -- a String key identifying the injection point, 'this' or null if the target method is static and the Object array. There can also be epilogue code following the call to unpack and reassign local state but in your case the rule does no assignment of locals or param so the bytecode following the call is just the original code. As well as this callout there is some exception handler plumbing to deal with THROW and RETURN actions or errors occuring during execution of the rule IF/DO clauses. That's actually the most complicated part of the transform so I'll not bother going into detailed explanation here.

     

    Anyway, given that the code has clearly been injected and that the verifier has accepted this transformed code then it looks as if there is not an error in the transformation process itself. Now the interesting thing is what happens at retransform. I think this is a problem in the JRockit VM rather than Byteman. Here is why.

     

    When the Byteman agent listener is asked to uninject a rule it removes the rule from the agent's in-memory 'database' of loaded rules then asks the JVM to retransform all the classes into which the rule had previously been injected. The trace printout shows the agent retransforming the one affected class, HubServicesDb. This trace is printed when the agent calls InstrumentationImpl.retransformClasses, asking the VM to start the bytecode rewrite process. You can see the call in teh exception stack listing. What is supposed to happen next is that the VM finds the original loaded bytecode (i.e. the code that was passed to Byteman when it was first asked to inject the rule) and lets the agent have another go at transforming it. Since the rule is no longer in the agent's in-memory 'database'  the Byteman transformer hands the byecode straight back to the VM without any changes being applied. So, the exception indicates that there is a problem in the bytecode the VM has used to do the retransform. This seems also to be confirmed by the fact that the same code works on Windows with the WIndows JVM. So, I am afraid this looks like it is a problem which can only be explained/resolved by the JRockit team -- actually, it looks like maybe they have already resolved it since the release I have does work.

     

    Den Galley wrote:

     

    Unfortunately, I can't use a different version of Jrockit JVM since 1.6.0.5 is our standard version. For me to be able to use byteman, I would need this issues resolved. Please let me know if there is anything else I should be trying to get more clues as to what is happening here.

     

    Well, I'm sorry you cannot currently upgrade in order to use Byteman (it's a immensely powerful and useful testing tool) but I understand that this is not a simple step when you have an app in deployment or even just nearing deployment. You could perhaps try askiing someone in the Oracle JRockit team if they can pin down the problem and see if there is a workaround -- I'd be very happy to correspond with them to explain what is going wrong and try to help fix it. I hope you will be able to use Byteman when you move forward to a later JRockit release.

     

    regards,

     

     

    Andrew Dinn