-
1. Re: bmcheck script transformation exception.
adinn Feb 14, 2012 9:08 AM (in response to whitingjr)1 of 1 people found this helpfulHi 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.
whitingjr Feb 14, 2012 9:22 AM (in response to adinn)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.
whitingjr Feb 14, 2012 10:44 AM (in response to whitingjr)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.
adinn Feb 14, 2012 11:38 AM (in response to whitingjr)1 of 1 people found this helpfulJeremy 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