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).

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