I have grammar with a semantic predicate in a subrule which requires initialization to be done in the invoking rule in order to execute properly e.g..
decl_specifier_seq
#init {
//some initialization required by a semantic predicate
}
: decl_specifier+ ;
decl_specifier
:
storage_class_specifier //auto, register, static, extern, mutable
| {/*semantic predicate requiring the initialization*/}? type_specifier
| function_specifier //inline, virtual, explicit
;
But some tests show that the semantic predicate throws NullPointerException because it is called before the initialization in the #init{} block of the invoking rule is ever called.
After checking the generated Parser code, I found that there is another function containing my semantic predicate:
private boolean decl_specifier_sempred(Decl_specifierContext _localctx, int predIndex)
It seems that this function is called before my #init{} block is called to do the initialization. Is it a bug or something by design? The exception contains the name of the above function:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.antlr.v4.runtime.misc.TestRig.process(TestRig.java:249)
at org.antlr.v4.runtime.misc.TestRig.process(TestRig.java:211)
at org.antlr.v4.runtime.misc.TestRig.main(TestRig.java:143)
Caused by: java.lang.NullPointerException
at cppParser.CPPProcessorParser.decl_specifier_sempred(CPPProcessorParse
r.java:10989)
at cppParser.CPPProcessorParser.sempred(CPPProcessorParser.java:10853)
at org.antlr.v4.runtime.atn.SemanticContext$Predicate.eval(SemanticConte
xt.java:119)
at org.antlr.v4.runtime.atn.ParserATNSimulator.evalSemanticContext(Parse
rATNSimulator.java:1295)
at org.antlr.v4.runtime.atn.ParserATNSimulator.execATN(ParserATNSimulato
r.java:539)
at org.antlr.v4.runtime.atn.ParserATNSimulator.adaptivePredict(ParserATN
Simulator.java:415)
at cppParser.CPPProcessorParser.cppCompilationUnit(CPPProcessorParser.ja
va:330)
... 7 more
The exception is encountered before the #init{} block is called.
ANTLR 4 determines the behavior of predicates based on whether or not they are "context sensitive". Context sensitive predicates use the $ syntax to reference a parameter, label, local, or rule/token defined in the current rule. It appears in your case you are defining and initializing state information outside of the standard ANTLR syntax, so it has no way to know the predicate is context sensitive. There are two ways to address this issue:
Define one or more of your state variables which are used in the predicate in a locals block for the rule instead of in a #members block.
Add a reference to $ctx inside of a comment in the predicates. For example, you could add /*$ctx*/ at the end of the predicate.
If a context sensitive predicate is encountered but no context information is available (as is the case for your code), the predicate is assumed to be true.
Related
Hi getting the below error with dexguard and I have also excluded the android.support.v7.app in rule
java.lang.VerifyError: Verifier rejected class android.support.v7.app.AppCompatDelegate: void android.support.v7.app.AppCompatDelegate.() failed to verify: void android.support.v7.app.AppCompatDelegate.(): [0x0] Constructor returning without calling superclass constructor (declaration of 'android.support.v7.app.AppCompatDelegate' appears in /data/app/com.intradiem.agentmobile-nzRaODeKWvj81AKePijb-A==/base.apk)
at android.support.v7.app.AppCompatDelegate.setCompatVectorFromResourcesEnabled(:525)
at com.intradiem.agentmobile.IntradiemApplication.(:27)
at java.lang.Class.newInstance(Native Method)
at android.app.Instrumentation.newApplication(Instrumentation.java:1102)
at android.app.Instrumentation.newApplication(Instrumentation.java:1087)
at android.app.LoadedApk.makeApplication(LoadedApk.java:983)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5715)
This sounds like a problem with the -assumenosideeffects rule.
Ensure that you do not use wildcards in combination with this rule, like that:
-assumenosideeffects class XXX {
*;
}
This will also remove calls to the superclass constructors as you experience it.
I am trying to get a set of the distinct values of an object's field stored in a Hazelcast map.
This line of java code:
instructions.aggregate(Supplier.all(value -> value.getWorkArea()), Aggregations.distinctValues());
has the following stacktrace :
java.util.concurrent.ExecutionException: com.hazelcast.nio.serialization.HazelcastSerializationException: java.lang.ClassNotFoundException: com.example.instruction.repository.HazelcastInstructionRepository$GeneratedEvaluationClass
com.hazelcast.nio.serialization.HazelcastSerializationException: java.lang.ClassNotFoundException: com.example.instruction.repository.HazelcastInstructionRepository$GeneratedEvaluationClass
java.lang.ClassNotFoundException: com.example.instruction.repository.HazelcastInstructionRepository$GeneratedEvaluationClass
If I were to try this line :
instructions.aggregate(Supplier.all()), Aggregations.distinctValues());
or:
instructions.aggregate(Supplier.fromPredicate(Predicates.and(Predicates.equal("type", "someType"), equal("groupId", null),
Predicates.equal("workArea", "someWorkArea"))), Aggregations.distinctValues());
It just works ... It seems to be something wrong when I am making a reference to the object's field. (I also tried it with other fields of the object and the same error gets returned)
This is running on my local environment and I am sure that the objects are being placed correctly in the Hazelcast map since the other aggregations/predicates are working.
Do you have any ideas about what am I doing wrong?
Many Thanks!
EDITED: So the problem is the closure. It's not available on all nodes. Only on the calling node.
Also. This feature is deprecated. Plz use the fast-aggregations instead.
http://docs.hazelcast.org/docs/latest/manual/html-single/#fast-aggregations
I don't know if this is a bug or a feature, but it's definitely unintuitive to people from a Java background to track the reason of exception.
Groovy allows variables to be referred to even if the variable is not defined.
For example consider the below class:
class B {
def infos;
public B(String param)
{
infos = param
}
public getInfo()
{
return info;
}
}
If you noticed, inside getInfo(), I am returning info which is never defined. However, Eclipse does not give a warning. So I continue on writing following:
class A
{
static main(def args)
{
B bObj = new B("Mahesh")
println "Hello groovy"
println bObj.getInfo()
println "Hello groovy"
}
}
Now this gives StackOverflowError with a huge stack trace:
Exception in thread "main" java.lang.StackOverflowError
at java.lang.Exception.<init>(Exception.java:102)
at java.lang.ReflectiveOperationException.<init>(ReflectiveOperationException.java:89)
at java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:72)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl$GetBeanMethodMetaProperty.getProperty(MetaClassImpl.java:3493)
at org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.callGroovyObjectGetProperty(GetEffectivePogoPropertySite.java:67)
--> at packages.B.getInfo(ThreadDumpsExp.groovy:169) <--
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl$GetBeanMethodMetaProperty.getProperty(MetaClassImpl.java:3493)
at org.codehaus.groovy.runtime.callsite.GetEffectivePogoPropertySite.callGroovyObjectGetProperty(GetEffectivePogoPropertySite.java:67)
:
:
The stack trace here was ok since somewhere down in the stack trace it pointed to this specific line which I highlighted in the above stack trace with arrows. I was expecting this line in the stack trace, that's why I was able to quickly track it down. The issue arose when today I came across same issue in my project. The stack trace was equally huge. I had no idea where it is actually going wrong so I can not make a guess about which line might actually be faulting. Worst it was stopping in Groovy's source during debugging. I had to repeatedly put breakpoints at different places to actually halt the execution at them. After some time I found the line where the debugger actually stopped inside my code. From there I stepped through my whole code to find the line which was causing issue. That line was a simple getter which was returning te wrong thing.
Now I know I should be more conscious while writing code and should not make such mistakes of returning a non-existent variable from a getter. But is there any way to make it not do what it did above?
Edit
Also after adding #TypeChecked, below error occurs. It was working properly earlier.
When you add a getter for a property, regardless of whether the property exists, you need to reference the property with the .# operator. This is the direct field access operator, which skips any getter and goes straight to the property. If you don't use the operator the same getter will be invoked over and over until you get a StackOverflowError.
For example:
def getInfo() {
return this.#info
}
See Section 6.2 Direct field access operator in the Groovy operator docs for a little more.
The problem lies in the signature of the getInfo-Method which implies that this is a getter. When you call a property of a class (here with "return info") than implicitly groovy uses the getter getInfo. This creates a endless loop which results in the StackOverflowError (because info calls getInfo, getInfo calls info, calls getInfo ...). If you use another not-existing property in here (i.e. return foo) you receive the expected MissingPropertyException. To avoid this behavior you should not define getter-Methods with names matching to not-existing properties.
I am trying to load some object through bytecode modification using asm bytecode instrumentation library.
I am retransforming the classes using retransformClasses() method.
I am loading the objects in this way :
super.visitVarInsn(Opcodes.ALOAD, 0);
super.visitFieldInsn(Opcodes.GETFIELD, owner, name, desc);
super.visitMethodInsn(org.objectweb.asm.Opcodes.INVOKESTATIC,
"com/coolcoder/MyClass",
"objectCheckTest",
"(Ljava/lang/Object;)V");`
The problem is that I the objects are getting loaded using usual tranform() of ClassTransformer , but when I am using Attach API's retranformClasses() , these objects are not getting loaded . Strange thing is that , I am not getting any bytecode error either.
Am I doing something wrong ? or am I missing some intricate part regarding retransform ?
I was be able to solve the issue , though I do not know why it happened in the first place.
(1) I was loading the object only on PUTFIELD or PUTSTATIC opcodes, i.e , when the object value is being set.
(2) Just after bytecode modification the class is getting redefined , as a result of which the code snippet did not work.
(3) Next time when the class loaded due to redefinition , the object is already being set , so it will not be called again.
(4) Now , when I checked for GETFIELD or GETSTATIC opcodes , i.e when the object's value is being retrieved and I loaded it , I was able to view its details.
The same approach which I mentioned above is working fine in usual transformation (i.e running with premain).
Any idea on this erratic behaviour of redefinition ?
First, in manifest.mf file,Can-Retransform-Classes attribute should be true.
And your ClassFileTransformer instance should be add with the true value for parameter canRetransform in method addTransformer .
Here is another additional tips:
If the transformer throws an exception (which it doesn't catch), subsequent transformers will still be called and the load, redefine or retransform will still be attempted. Thus, throwing an exception has the same effect as returning null. To prevent unexpected behavior when unchecked exceptions are generated in transformer code, a transformer can catch Throwable. If the transformer believes the classFileBuffer does not represent a validly formatted class file, it should throw an IllegalClassFormatException; while this has the same effect as returning null. it facilitates the logging or debugging of format corruptions.
from java api docs
So, there maybe some uncatched exception which will be just ignored by the jvm arised.
You can put a try..catch
Please forgive my poor English ...
What is the meaning of groovy.lang$run.call(Unknown Source) and on what circumstances it will throw, this is the error what i'm getting in my groovy program
at groovy.lang$run.call(Unknown Source)
at groovy.lang.run(groovy.lang.Two_Script:6)
...................................................
...................................................
at groovy.lang.run(groovy.lang.Two_Script:6)
at groovy.lang$run.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:121)
at one_script.run(level_one_script.groovy:5)
why it has not thrown at the compile time only # runtime it has thrown any Idea ?
attached the sample groovy these are very simple recursive calls;
level_one_script.groovy
new Two_Script(binding).run()
Two_Script.groovy
new Three_Script().run()
Three_Script.groovy
println "Anish"
the exception was thrown while evaluating Three_Script.groovy , it give me recurive call on Two_Script.groovy
Exception occurred while executing the script [level_one_script.groovy] - [java.lang.StackOverflowError].
try
{
compiledScript.eval(bindings)
//compiledScript is the type of CompiledScript
}
Surprising part is if i remove the call new Three_Script().run() from "Two_Script.groovy"
it shows me correct result
Surprising
If the Groovy scripts are all defined in a package, the error is not thrown.
If the scripts are moved to the default package (no package), the error is thrown.
What is the actual exception thrown (first few lines)
Looks like there's problem in your file level_one_script.groovy at line 5