4 Replies Latest reply: Feb 14, 2012 11:38 AM by Andrew Dinn RSS

bmcheck script transformation exception.

Jeremy Whiting Apprentice

Hi,

I am debugging a possible JDK issue. To do this I am using Byteman to debug when a condition occurs. The rule is for a class in the java.security package and at runtime I have put Bytman on the boot classpath.

 

Running bmcheck  I am getting an unexpected exception. This the ouput of the bmcheck execution.

 

$ ~/java/jboss/byteman/byteman-download-2.0.0/bin/bmcheck.sh  EntitySerializationTest/src/main/resources/ProtectionDomainWithouthasAllPermDebug.txt

checking rule PermDomainWithouthasAllPermTrue

ERROR : Unexpected exception transforming class java.security.ProtectionDomain using  rule "PermDomainWithouthasAllPermTrue" loaded from EntitySerializationTest/src/main/resources/ProtectionDomainWithouthasAllPermDebug.txt line 8

 

java.lang.Error: Failed to transform class java.security.ProtectionDomain using rule PermDomainWithouthasAllPermTrue

 

TestScript: 1 total errors

            0 total warnings

            0 parse errors

            0 type errors

            0 type warnings

 

 

 

This is the script

 

  1. A rule to debug the creation of a ProtectionDomain without the

  2. hasAllPerm condition.

 

RULE PermDomainWithouthasAllPermTrue

CLASS java.security.ProtectionDomain

METHOD

AT EXIT

IF !$hasAllPerm

DO debug("["$this.toString()"] [" + $permission.toString()+ "]" );

traceStack()

ENDRULE

 

 

I am using the distribution version 2.0.0 of Byteman.

Is this an error that Bytman is not handling because the rule is working on a class in the java.security package ?

 

Regards,

Jeremy

  • 1. Re: bmcheck script transformation exception.
    Andrew Dinn Master

    Hi Jeremy,

     

    I don't think it makes any difference what package the targte class belongs to. It looks to me like you have an error in your rule

     

    RULE PermDomainWithouthasAllPermTrue

    CLASS java.security.ProtectionDomain

    METHOD

    AT EXIT

    IF !$hasAllPerm

    DO debug("["$this.toString()"] [" + $permission.toString()+ "]" );

    traceStack()

    ENDRULE

     

     

    You appear to be missing some String '+' operators on the first line of the action clause

     

    DO debug("[" + $this.toString() + "] [" + $permission.toString()+ "]" );

     

    You could try running bmcheck.sh to check you script offline just to make sure this works (n.b. since java.security.ProtectionDomain  is a bootstrap class you don't need to add any -cp arguments between bmcheck.sh and the script name).

  • 2. Re: bmcheck script transformation exception.
    Jeremy Whiting Apprentice

    Hi Andrew,

    Yes I have been using the bmcheck script as you suggested to find any errors in my rule. The output from bmcheck is above in my first post. The error looks strange and is only showing a count of 1 in the total errors. The error count by category does not reveal the root cause.

     

    My script does already have the missing String '+' operators. The Magnolia editor stripped the operators out of my original post. Thank you for pointing that out but it is not the reason for the message returned by bmcheck.

     

    Here is my script again. I will check it after adding submitting the reply for any stripped out characters.

     

     

    # A rule to debug the creation of a ProtectionDomain without the

    # hasAllPerm condition.

     

    RULE PermDomainWithouthasAllPermTrue

    CLASS java.security.ProtectionDomain

    METHOD <init>

    AT EXIT

    IF !$hasAllPerm

    DO debug("["+$this.toString()+"] [" + $permission.toString()+ "]" );

    traceStack()

    ENDRULE

     

    Regards,

    Jeremy

  • 3. Re: bmcheck script transformation exception.
    Jeremy Whiting Apprentice

    Hi,

    This did turn out to be coding mistakes defining the condition. Two things were done. Separate out the debug messages and correct the condition in the rule script to reference the field 'hasAllPerm' through 'this'. This is the rule correctly written.

     

    # A rule to debug the creation of a ProtectionDomain without the

    # hasAllPerm condition.

     

    RULE PermDomainWithouthasAllPermTrue

    CLASS java.security.ProtectionDomain

    METHOD <init>

    AT EXIT

    IF !$this.hasAllPerm

    DO debug($this.toString());

       debug($permissions.toString())

    ENDRULE

     

    Thank you for your suggestions Andrew.

     

    Regards,

    Jeremy

  • 4. Re: bmcheck script transformation exception.
    Andrew Dinn Master

    Jeremy Whiting wrote:

     

    Hi Andrew,

    Yes I have been using the bmcheck script as you suggested to find any errors in my rule. The output from bmcheck is above in my first post.

    Doh! Aplologies. I really ought to read more carefully!

     

    Ok, what's the deal with the unhelpful error message? Well, it is because Byteman cannot be sure there is an error here. In fact, at runtime it will just ignore this rule and not inject it and it will only print warning messages if you enable verbose trace. Why? Well, it's not actually straightforward but it is about ambiguity.

     

    The error from bmcheck is this:

     

    ERROR : Unexpected exception transforming class java.security.ProtectionDomain using  rule "PermDomainWithouthasAllPermTrue" loaded from EntitySerializationTest/src/main/resources/ProtectionDomainWithouthasAllPermDebug.txt line 8

     

    java.lang.Error: Failed to transform class java.security.ProtectionDomain using rule PermDomainWithouthasAllPermTrue

     

    TestScript: 1 total errors

                0 total warnings

                0 parse errors

                0 type errors

                0 type warnings

     

    What this does tell you is that the rule was parseable and that there was a matching class and method. Why? Well, it tired to inject the rule into a class, so it must have found a matching method. However, it was not possible to inject the rule into the target method. This is clearly not because of a type error otherwise you would have been told about a type exception. In fact it is teling you it never got as far as transforming the class, never mind trying to type check the rule. So,  this emans that something in the rule specification does not actually match the target method making it invaldi to inject the rule. Clearly, the location matches since every method has at least one exit point so it must be somethign else.

     

    The problem is that in your first version you referred to local variable $hasAllPerm. Well, I know you didn't mean to but that's what the synatx of $name is -- a local var reference. What you intended was a field reference $this.hasallPerm. Since the target method does not include a local variable $hasAllPerm Byteman does not inject the rule. It will not do so because it knows the rule does not fit this case. This mismatch is regarded as noteworthy when bmcheck finds it hence why it prints a message and counts an error. However, it may or may not actually be an error. In fact, bmcheck really ought to generate a warning in this case  rather than an error (don't worry, I'll raise a JIRA for this).

     

    The ambiguity arises because there might be another target class/method in your app (or in JVM code) which does include a local variable with this name. So, just because the rule does not match this class it might be appropriate somewhere else and complaining about it is not necessarily the right thing to do. In cases where there is a determinate (package-qualified) class name and a determinate (signature-qualified) method name there does not appear to be much room for doubt as to whether this is an error. However, even there it may be that two different deployments have different versions of a class with different local vars. So, Byteman shoudl not really make any assumptions that a specific failure to inject represents an error. Indeed at runtime the agent simply decides quietly not to inject a rule if it finds that it cannot resolve local var references.

     

    So, I know this is confusing and I will try to improve the injection code so that it generates a warning mentioning the specific problem encountered. JIORA to follow.

     

    regards,

     

     

    Andrew Dinn