codespecs / daikon Goto Github PK
View Code? Open in Web Editor NEWDynamic detection of likely invariants
Home Page: http://plse.cs.washington.edu/daikon/
License: Other
Dynamic detection of likely invariants
Home Page: http://plse.cs.washington.edu/daikon/
License: Other
Originally reported on Google Code with ID 24
The java instrumentation code that DynComp inserts does not verify with Java 7 due to
StackMap issues.
You can work around this problem by compiling with -target 5 -source 5
Reported by [email protected]
on 2013-12-12 23:45:34
Originally reported on Google Code with ID 18
What steps will reproduce the problem?
1. javac -d bin -g src/com/example/AnAbstractClass.java
2. java -cp daikon.jar:bin daikon.Chicory --daikon com.example.AnAbstractClass
3. java -cp daikon.jar:bin daikon.tools.runtimechecker.Main instrument AnAbstractClass.inv.gz
src/com/example/AnAbstractClass.java
4. javac -cp bin:daikon.jar instrumented-classes/com/example/AnAbstractClass.java
What is the expected output?
A compiled class file named bin/com/example/AnAbstractClass.class
What do you see instead?
instrumented-classes/com/example/AnAbstractClass.java:5: error: illegal combination
of modifiers: abstract and private
private abstract boolean internal$anAbstractMethod();
^
instrumented-classes/com/example/AnAbstractClass.java:20: error: abstract methods cannot
have a body
public abstract boolean anAbstractMethod()
^
What version of the product are you using?
Nov 27 revision (27b35b7e3299)
On what operating system?
Darwin dhcp-139.st.cs.uni-saarland.de 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug
23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
Please provide any additional information below.
While visiting a MethodDeclaration, instrumentation should skip instrumenting the method
if the method is abstract. In order to do so add a check and a return at
daikon.tools.runtimechecker.InstrumentVisitor.visit(MethodDeclaration)
Reported by jgaleotti
on 2013-12-04 10:20:42
Originally reported on Google Code with ID 14
This doesn't appear to be true for default Fedora or Ubantu
Reported by [email protected]
on 2013-08-20 23:34:35
Originally reported on Google Code with ID 27
I'm new to daikon and want to use it to detect invariants in junit tests. However it
doesn't work on my computer.
I use the latest daikon (5.0.2).Here's an example of the commands I typed:
cd ~/daikon
source scripts/daikon.bashrc
java daikon.Chicory --daikon org.junit.runner.JUnitCore
The output shows:
Executing target program: java -cp /home/song/daikon/daikon.jar:/home/song/daikon/daikon.jar:/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/lib/tools.jar:/usr/lib/jvm/java/jre/lib/rt.jar:/usr/lib/jvm/java/lib/tools.jar
-ea -Xmx1000m -javaagent:/home/song/daikon/java/ChicoryPremain.jar=--daikon --dtrace-file=JUnitCore.dtrace.gz
org.junit.runner.JUnitCore
entered daikon.chicory.Runtime.setDtrace(./JUnitCore.dtrace.gz, false)...
Exception in thread "main" java.lang.VerifyError: (class: org/junit/runner/Computer$1,
method: <init> signature: (Lorg/junit/runner/Computer;Lorg/junit/runners/model/RunnerBuilder;)V)
Register 1 contains wrong type
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(ClasChicory warning: no records
were printed
s.java:2493)
at java.lang.Class.getConstructor0(Class.java:2803)
at java.lang.Class.getDeclaredConstructor(Class.java:2053)
at daikon.chicory.MethodInfo.initViaReflection(MethodInfo.java:141)
at daikon.chicory.ClassInfo.initViaReflection(ClassInfo.java:81)
at daikon.chicory.Runtime.process_new_classes(Runtime.java:436)
at daikon.chicory.Runtime.enter(Runtime.java:246)
at org.junit.runner.JUnitCore.main(JUnitCore.java:45)
Warning: Did not run Daikon because target exited with 1 status
And here's my java version:
java version "1.7.0_51"
OpenJDK Runtime Environment (fedora-2.4.4.1.fc19-x86_64 u51-b02)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
I'd like to know whether I can use daikon for junit tests or there's some limits for
that. Thank you.
Best Regards,
Maxime Song
Reported by [email protected]
on 2014-02-27 19:52:39
Originally reported on Google Code with ID 9
daikon.dcomp.BuildJDK assumes that all classes will contain a classname with multiple
components. The Oracle 1.7.0_21 rt.jar violates this assumption; throwing Error caused
by a NullPointer exception.
Exception in thread "main" java.lang.Error: Couldn't instrument WrapperGenerator$1
at daikon.dcomp.BuildJDK.translate_classes(BuildJDK.java:351)
at daikon.dcomp.BuildJDK.main(BuildJDK.java:189)
Caused by: java.lang.NullPointerException
at java.io.File.<init>(File.java:334)
at daikon.dcomp.BuildJDK.processClassFile(BuildJDK.java:391)
at daikon.dcomp.BuildJDK.translate_classes(BuildJDK.java:349)
... 1 more
I have attached a copy of my modified BuildJDK source; modifications are between lines
391 and 397. The build completes cleanly but I haven't done any meaningful regression
testing.
Reported by [email protected]
on 2013-04-25 16:26:22
Daikon version: 5.2.0
JDK version: 1.7.0_71
System: Mac OS El Capitan (10.11.3)
Description:
For the given dtrace file (shared), I execute Daikon on it and it works as normal. The command I run is:
java daikon.Daikon bug_report.dtrace.gz
The method I am interested is org.apache.commons.bcel6.util.Class2HTML.Class2HTML(..), which is the contructor for Class2HTML class. In the output of the above command, the invariants are there, also the Class invariants and Object invariants for that class are both there. All looks great.
However, when I need to get exactly that method's invariants using --ppt-select-pattern, on the exactly same dtrace file, it encounters a weird exception. The command I run and the exception is as follows: (its full output is shared in a file.)
java daikon.Daikon bug_report.dtrace.gz --ppt-select-pattern='^org.apache.commons.bcel6.util.Class2HTML.Class2HTML('
Exception in thread "main" java.lang.RuntimeException: parent ppt org.apache.commons.bcel6.util.Class2HTML:::OBJECT not found for ppt org.apache.commons.bcel6.util.Class2HTML.Class2HTML(org.apache.commons.bcel6.classfile.JavaClass, java.lang.String):::EXIT
at daikon.PptRelation.init_hierarchy_new(PptRelation.java:982)
at daikon.Daikon.process_data(Daikon.java:1954)
at daikon.Daikon.mainHelper(Daikon.java:573)
at daikon.Daikon.main(Daikon.java:453)
What is odd, is that what is complained in the exception seems not true, because in the previous execution (without filter) the Object invariants are indeed in the output.
Looks like the -ppt-select-pattern filter does not work correctly in this case.
To recreate the bug:
Because of the large file size, all of the files required to recreate the bug are uploaded online instead of being attached in this report. You can find and download them here. If this link does not work, you can copy and paste the url below to open files.
https://drive.google.com/folderview?id=0B2ErS1V8NMeXRkNuclVpQUJUNFE&usp=sharing
There are three files shared:
bug_report.dtrace.gz - the dtrace file to extract invariants from
full_inv_out.txt - the full output after executing without filter:
java daikon.Daikon bug_report.dtrace.gz
(You will see the invariants there)
filter_inv_out.txt - the full output (with all exception information) after executing Daikon with filter:
java daikon.Daikon bug_report.dtrace.gz --ppt-select-pattern='^org.apache.commons.bcel6.util.Class2HTML.Class2HTML('
(You will see the exception and no invariants are extracted)
Originally reported on Google Code with ID 5
What steps will reproduce the problem?
1. Run the command java -Xmx2048m -classpath daikon.Chicory --heap-size=2048m --daikon
MyClass
What is the expected output? What do you see instead?
I expect to see Daikon running with 2048 MB of ram, instead it defaults to 500
What version of the product are you using? On what operating system?
The version downloadable from the website.
Please provide any additional information below.
Running on Mac OS
Reported by ti.veloso
on 2011-02-24 18:44:18
Originally reported on Google Code with ID 13
several references to /afs/csail.mit.edu at top of file
Reported by [email protected]
on 2013-08-20 23:31:36
Originally reported on Google Code with ID 25
What steps will reproduce the problem?
1. cd daikon_root_folder
2. make
3.
What is the expected output? What do you see instead?
make[4]: Entering directory `/dcs/pg11/fatimah/DAIKON/daikon/kvasir/valgrind/coregrind'
Makefile:114: *** missing separator. Stop.
make[4]: Leaving directory `/dcs/pg11/fatimah/DAIKON/daikon/kvasir/valgrind/coregrind'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/dcs/pg11/fatimah/DAIKON/daikon/kvasir/valgrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/dcs/pg11/fatimah/DAIKON/daikon/kvasir/valgrind'
make[1]: *** [kvasir] Error 2
make[1]: Leaving directory `/dcs/pg11/fatimah/DAIKON/daikon'
make: *** [all] Error 2
What version of the product are you using? On what operating system?
Red Hat Enterprise Linux Workstation release 6.1 (Santiago)
Linux version 2.6.32-358.6.2.el6.x86_64.debug ([email protected])
(gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Tue May 14 15:56:58 EDT
2013
Please provide any additional information below.
Reported by faateemahfika
on 2013-12-28 06:21:10
Originally reported on Google Code with ID 44
Project Member Reported by [email protected], Feb 21, 2014
After running the daikon/test/daikon-tests for the csharp format, I observed a number
of incorrect contracts involving derived array splices.
Here are two contracts generated for the QueueAr test:
Contract.ForAll(0, this.theArray.Slice(orig(this.front)+1, this.theArray.Count()-1).Count(),
i => this.theArray.Slice(orig(this.front)+1, this.theArray.Count()-1)[i].Equals(this.theArray.Slice(orig(this.front)+1,
Contract.OldValue(this.theArray).Count()-1)[i]))
Contract.ForAll(0, this.theArray.Slice(0, orig(this.front)-1).Count(), i => this.theArray.Slice(0,
orig(this.front)-1)[i].Equals(this.theArray.Slice(0, orig(this.front)-1)[i]))
These contracts get generated by the file derive/binary/SequenceSubsequence.java in
this code:
public String csharp_name(String index) {
String lower = get_lower_bound().csharp_name();
String upper = get_upper_bound().csharp_name();
return seqvar().csharp_name() + ".Slice(" + lower + ", " + upper + ")";
}
A few observations:
1) Somewhere 'orig(..)' is not being properly translated to 'Contract.OldValue(..)'.
I tried rewriting the code similar to what JML does, but did not have success.
2) The Slice method is not currently part of CSharpDaikonLib.
3) I have never seen contracts of this format before. Perhaps we have never turned
on this derived variable?
4) There could potentially be other bugs in derived variables we have not tested
I attached the diff file were I observed these contracts. There are many other examples
of it inside the file.
QueueAr.txt-csharpcontract.diff
29.6 KB Download
Mar 16, 2014 Delete comment Project Member #1 [email protected]
I changed this to output an unimplemented message.
Reported by [email protected]
on 2015-05-04 15:32:18
Originally reported on Google Code with ID 16
What steps will reproduce the problem?
java daikon.Chicory DataStructures.StackArTester
What is the expected output? What do you see instead?
mian@mian-VirtualBox:~/daikonparent/daikon/examples/java-examples/StackAr$ java daikon.Chicory
DataStructures.StackArTester
Executing target program: java -cp .:/home/mian/daikonparent:/daikon:/home/mian/daikonparent/daikon/daikon.jar:/home/mian/daikonparent/daikon/bin/daikon.bashrc
-ea -Xmx128M -javaagent:/home/mian/daikonparent/daikon/daikon.jar= --dtrace-file=StackArTester.dtrace.gz
DataStructures.StackArTester
entered daikon.chicory.Runtime.setDtrace(./StackArTester.dtrace.gz, false)...
CLASSPATH component /home/mian/daikonparent/daikon/bin/daikon.bashrc: java.util.zip.ZipException:
error in opening zip file
What version of the product are you using? On what operating system?
I am using the one that can be downloaded from website (daikon.tar.gz). I am using
ubuntu 12.04 LTS stable.
Please provide any additional information below.
It look like either the gunzip app in OS is not recognized or the file format is not
readable or dont know :)
Reported by mianasbat
on 2013-11-07 10:54:55
Originally reported on Google Code with ID 10
What steps will reproduce the problem?
1. Attempt to run Chicory on the provided file, which compiles with Eclipes and javac,
and runs normally.
What is the expected output? What do you see instead?
The expected behavior is that Chicory terminates and a datatrace is output. Instead
Chicory crashes with this error message:
Executing target program: java -cp C:\cygwin\home\Kellen\daikon\daikon.jar;.;C;C:\Program
Files\Java\jdk1.7.0_07\lib\tools.jar;C;C:\Program
Files
(x86)\Java\jre7\lib\ext\QTJava.zip;C;C:\cygwin\home\Kellen\daikon\daikon.jar;C:\Program
Files\Java\jdk1.7.0_07\jre\lib\rt.jar;C:\Program Files\Java\jdk1.7.0_07\lib\tools.jar
-ea -Xmx1000m -javaagent:C:\cygwin\home\Kellen\daikon\daikon.jar= --dtrace-file=HelloWorld.dtrace.gz
HelloWorld
entered daikon.chicory.Runtime.setDtrace(.\HelloWorld.dtrace.gz, false)...
Exception in thread "main" java.lang.Error: can't find method fooB
at daikon.chicory.MethodInfo.initViaReflection(MethodInfo.java:146)
at daikon.chicory.ClassInfo.initViaReflection(ClassInfo.java:81)
at daikon.chicory.Runtime.process_new_classes(Runtime.java:430)
at daikon.chicory.Runtime.enter(Runtime.java:240)
at HelloWorld.main(HelloWorld.java:6)
Caused by: java.lang.NoSuchMethodException: HelloWorld.fooB(byte)
at java.lang.Class.getDeclaredMethod(Class.java:1954)
e at dCahiikcoonr.yc hwiacronriyn.gM:e tnhoo drIencfoor.disn iwteVrie apRreifnlteecdtion(M
thodInfo.java:143)
... 4 more
Warning: Target exited with 1 status
What version of the product are you using? On what operating system?
javac 1.7.0_07, Daikon version 4.6.4, Win7 under cygwin
Please provide any additional information below.
The problem seems to disappear if all the classes are in separate files.
Reported by melonhead901
on 2013-06-04 10:50:05
Originally reported on Google Code with ID 3
Daikon can handle multiple input files from multiple runs of the target
program.
but it (and chicory) don't have any mechanism to merge the files created by
multiple runs of dyncomp. Essentially this would need to merge the
comparabilities
across the various runs. There may well be code that does this, but it
isn't organized
into a tool and is certainly not automatically supported by either chicory or
daikon
Reported by [email protected]
on 2010-04-15 19:49:04
Originally reported on Google Code with ID 17
What steps will reproduce the problem?
1. Unzip the attached file
2. java -cp daikon.jar:bin daikon.tools.runtimechecker.Main instrument DataStructures.QueueArEvoSuiteTest0.inv.gz
src/DataStructures/QueueAr.java
3. javac -cp bin:daikon.jar instrumented-classes/DataStructures/QueueAr.java
What is the expected output?
A compiled QueueAr.class
What do you see instead?
instrumented-classes/DataStructures/QueueAr.java:420: error: incomparable types: boolean
and int
if ( !((retval_instrument != 0) == (this.currentSize == 0)) )
^
instrumented-classes/DataStructures/QueueAr.java:989: error: incomparable types: boolean
and int
if ( !((retval_instrument != 0) == (retval_instrument == true)) )
^
instrumented-classes/DataStructures/QueueAr.java:1431: error: incompatible types
if ( !(daikon.Quant.subsetOf(this.theArray, new long[] { null, 1964752463
})) )
^
required: long
found: <null>
instrumented-classes/DataStructures/QueueAr.java:1645: error: incompatible types
if ( !(daikon.Quant.subsetOf(this.theArray, new long[] { null, 1964752463
})) )
^
required: long
found: <null>
instrumented-classes/DataStructures/QueueAr.java:1850: error: incompatible types
if ( !(daikon.Quant.subsetOf(this.theArray, new long[] { null, 1096993286
})) )
^
required: long
found: <null>
What version of the product are you using?
Daikon release 4.7.3
On what operating system?
Darwin dhcp-139.st.cs.uni-saarland.de 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug
23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
Please provide any additional information below.
I think that the problem is located in
daikon.inv.unary.sequence.EltOneOf (the null being printed in the new long[] array)
and
daikon.inv.unary.scalar.NonZero
Reported by jgaleotti
on 2013-12-04 09:11:59
Originally reported on Google Code with ID 29
There is a problem with decomp/BuildJDK.java. This is the tool used to build dcomp_rt.jar.
It creates a list of the classes it has instrumented and stores it in dcomp-rt/java/lang/jdk_classes.txt.
It was just letting program termination close this file and it was not getting flushed
first. This meant that about 500 classes were instrumented but not put on the list.
When dyncomp was run, depending on the methods the program used, it might try to reinstrument
and instrumented runtime routine. This leads to very nasty behavior.
Reported by [email protected]
on 2014-04-04 17:51:12
Originally reported on Google Code with ID 43
Project Member Reported by [email protected], Feb 21, 2014
After merging with the main Daikon tree and running the tests inside /tests/daikon-tests,
there are 87 failures. 27 of these failures are because csharp test goals have not
been updated. 4 of these failures were already present. This leaves 56 new failures.
I've attached the results of 'make summary' after running the tests.
test_summary.txt
19.1 KB View Download
Feb 21, 2014 Delete comment #1 [email protected]
I'm getting 95 failures (see attached). What is your time frame for updating the C#
contract?
Feb 21, 2014 Delete comment Project Member #2 [email protected]
I am getting 87 failures when I run only /tests/daikon-test. When I run all the tests
I get 95 failures like you, where the additional 8 are from /tests/chicory-tests.
Do you mean when I plan on updating the csharp goal files?
Feb 21, 2014 Delete comment #3 [email protected]
At a glance, it looks like many of the errors might be due to changes in how the orig
works for derived variables. For example:
-size(this.elementData[]) >= orig(size(this.elementData[]))
-size(this.elementData[])-1 >= orig(size(this.elementData[]))-1
+size(this.elementData[]) >= size(orig(this.elementData[]))
+size(this.elementData[])-1 >= size(orig(this.elementData[]))-1
This is mostly likely due to the change you made in a2086720bd03 which we needed to
fix the linking of orig variables to parent PPTs first introduced in my revision 45d28d97c397.
Feb 22, 2014 Delete comment Project Member #4 [email protected]
The majority of the differences do appear to be related to how orig works for derived
variables, but there are also changes I'm seeing in some other files that do not seem
related to this.
For example, here is TinySet.txt-jml.diff:
--- TinySet.txt-jml.goal 2014-02-20 16:07:31.808256874 -0800
+++ TinySet.txt-jml 2014-02-21 11:39:55.937329203 -0800
@@ -29,6 +29,16 @@
(\result == true) ==> (\old(this) != null)
(\result == true) ==> (this.bits > \old(n))
===========================================================================
+six170.TinySet.contains(int):::EXIT;condition="return == true"
+ Variables: this this.bits n return orig(this) orig(this.bits) orig(n)
+\result == true
+\old(this) != null
+this.bits > \old(n)
+===========================================================================
+six170.TinySet.contains(int):::EXIT;condition="not(return == true)"
+ Variables: this this.bits n return orig(this) orig(this.bits) orig(n)
+\result == false
+===========================================================================
six170.TinySet.intersect(six170.TinySet):::ENTER
Variables: this this.bits other other.bits
other != null
This is the addition of two new program points on the default splitter for boolean
returns.
Here is a portion of the diff from Suppress02.txt-esc.diff:
- Unmodified variables: this this.theArray this.theArray[] n size(this.theArray[])
this.theArray[n] this.theArray[n..] this.theArray[n+1..] this.theArray[0..n] this.theArray[0..n-1]
+ Unmodified variables: this this.theArray this.theArray[] n this.theArray[n]
this.theArray[n..] this.theArray[n+1..] this.theArray[0..n] this.theArray[0..n-1]
See my next post for a summary of the errors I am seeing.
Feb 22, 2014 Delete comment Project Member #5 [email protected]
There a few classes of differences I'm seeing in the test diffs:
1) orig(size(..)) versus size(orig(..)). This shows up both in invariants and in the
variable lists for program points
2) new program points on the default splitter for boolean returns. Another example
of this is RatPoly.txt-simplify.diff
3) changes in the unmodified variables lists. In particular, size(..) derived variables
have been removed from every unmodified variable list
From what I've seen, these differences represent the cause of every test failure (aside
from the non-updated csharp goals).
Like you said, we will probably have to have the targets updated for issue (1), but
I'm not sure what is going on with issues (2) or (3).
Do you have any ideas?
Feb 25, 2014 Delete comment Project Member #6 Todd.Schiller
For #2, did you ever make changes to how splitter PPTs are handled? I don't recall
making changes, so this would be a side effect. From the example you give, our output
looks like it might be correct but that there's some configuration issue going on (where
the splitter PPTs should not be printed out for that particular test).
For #3, can you double-check the test case to see what the correct output should be?
After that you're best bet is probably use the Eclipse debugger to figure out why the
size(this.theArray[]) is not being printed. I could imagine it being an orig(...) issue
where the pre-state and post-state variables are not being matched properly.
Reported by [email protected]
on 2015-05-04 15:29:18
Originally reported on Google Code with ID 15
doesn't seem very useful; refers to non existent directory (bin); and does not appear
to be mentioned in documentation.
Reported by [email protected]
on 2013-08-20 23:48:26
Originally reported on Google Code with ID 30
If we try to instrument a method with lots of arguments (didn't get the exact threshold;
5 works, 9 doesn't) the amount of instrumentation code is so large that its size won't
fit in a StackMap SAME_FRAME entry; we must use a SAME_FRAME_EXTENDED entry instead.
Reported by [email protected]
on 2014-04-04 20:28:30
Originally reported on Google Code with ID 12
diff with X86 about whether a location is STATIC or STACK. need to investigate
Reported by [email protected]
on 2013-08-05 22:54:37
Originally reported on Google Code with ID 36
When building dcomp_rt.jar based on a Java8 rt.jar, we get numerous failures due to
the new Lambda expression feature. This uses a previously unused java bytecode (InvokeDynamic)
that is not supported in BCEL.
The plan is to add this bytecode to our version of BCEL and then instrument a method
containing the invocation of a Lambda expression as normal, but to not instrument the
separated lambda expression methods.
Long term we assume we would be better off using ASM instead of BCEL, but the work
required to switch is too long to wait for this feature.
Reported by [email protected]
on 2014-11-14 19:07:14
Originally reported on Google Code with ID 42
originally reported by: [email protected]
Provide switches for the following:
* Whether boolean equality/inequality is expressed as == or using !
* Whether null guards are expressed using the Implies() extension method or using logical-or
Reported by [email protected]
on 2015-04-24 19:55:58
Originally reported on Google Code with ID 6
'make' fails on OS X because it is explicitly looking for tools.jar and rt.jar. These
libraries don't exist on OS X. Instead there is one 'classes.jar' that contains both
these libraries.
Additionally, classes.jar is NOT in $JAVA_HOME/lib, because the whole JRE directory
structure is different on OS X. 'classes.jar' is in $JAVA_HOME/../Classes (i.e. in
a directory Classes that is "parallel" to $JAVA_HOME).
I'll try to fix the makefile if I can work out a good way to do it.
Reported by wuttkej
on 2011-08-02 21:54:26
Originally reported on Google Code with ID 8
According to the Daikon documentation when the not_ordered flag is active "Daikon does
not check for element-wise comparisons between it and other collections." However,
when the not_ordered flag is specified some intra-sequence comparison, such as collection
sort order should also be disabled.
Reported by melonhead901
on 2012-04-13 11:02:34
Originally reported on Google Code with ID 2
When analysing following program with Daikon:
1. Command line:
daikon.Daikon trace1.dtrace.gz --format java --no_text_output --config
daikon/annotate_nullable.config
2. Source:
package example;
public final class Failure3 {
public Failure3() {
System.setSecurityManager(new SecurityManager()
{
@Override public final void checkPackageAccess( final String
pkg ) {
throw new SecurityException("access to package "+pkg+" not
allowed");
}
});
}
public static void main(String[] args) throws Exception {
new Failure3();
}
}
3. Problem:
Daikon version 4.6.0, released July 1, 2009;
http://pag.csail.mit.edu/daikon.
Processing trace data; reading 1 dtrace file:
No return from procedure observed 1 time. Unmatched entries are ignored!
Unterminated calls:
example.Failure3$1.checkPackageAccess(java.lang.String) : 1 invocation
End of report for procedures not returned from. Unmatched entries are
ignored!
[16:06:08]: Finished reading trace1.dtrace.gz
Exiting Daikon.
Reported by Stephan.Heiss
on 2009-09-10 14:09:25
Originally reported on Google Code with ID 1
package example;
public final class Failure2 {
public static void main(String[] args) throws Exception {
Runtime.getRuntime().addShutdownHook(new Thread()
{
public void run()
{
//noop
}
});
}
}
/*
When a shutdown hook is present, the Daikon analysis crashes:
>> daikon.Daikon trace1.dtrace.gz --format java --no_text_output --config
daikon/annotate_nullable.config
Daikon version 4.6.0, released July 1, 2009;
http://pag.csail.mit.edu/daikon.
Processing trace data; reading 1 dtrace file:
Error at line 183 in file trace1.dtrace.gz: Mismatch between .dtrace file
and .d
ecls file. Expected variable this, got for program point example.Failure2
$1.ru
n():::ENTER
>> here is the trace1 end produced with Chicory:
example.Failure2.main(java.lang.String[]):::EXIT13
this_invocation_nonce
0
args
9182681
1
args.getClass()
"java.lang.String[]"
1
args[..]
[]
1
args[..].toString
[]
1
example.Failure2$1.run():::ENTER
this_invocation_nonce
2
# EOF (added by Runtime.addShutdownHook)
*/
Reported by Stephan.Heiss
on 2009-09-10 13:58:48
DynComp for C's command-line argument names are inconsistently named.
I propose the following renamings.
--gc-num-tags => --dyncomp-gc-num-tags
--no-dyncomp-gc => --dyncomp-gc-num-tags=0
--dyncomp-fast-mode => --dyncomp-approximate-literals
--separate-entry-exit-comp => --dyncomp-separate-entry-exit
--dyncomp-dataflow-only => --dyncomp-interactions=none
--dyncomp-dataflow-comp => --dyncomp-interactions=comparisons
--dyncomp-units => --dyncomp-dataflow=units
[does not exist; is the default] => --dyncomp-dataflow=all
Originally reported on Google Code with ID 31
The old version was running into a problem for a PPT with name BankAccountNS.BankAccount.Debit(System.Double\_amount):::EXIT_EX_System.Exception.
Section "A.3.2 Program point declarations" states that the PPT name can include any
character. Obviously this script relies on the ":::" in the PPT name, though. So this
change is probably a good compromise.
Reported by Todd.Schiller
on 2014-07-14 02:04:52
Originally reported on Google Code with ID 33
What steps will reproduce the problem?
if java source file contains a Boolean constant declaration; e.g.:
private static final Boolean name = false;
then the commands:
javac -g test.java
java -cp .:$CLASSPATH daikon.Chicory test
java -cp .:$CLASSPATH daikon.Daikon test.dtrace.gz
What is the expected output? What do you see instead?
Instead of a list of program invariants, Daikon halts with an exception
at daikon.ProglangType.parse_value_scalar(ProglangType.java:440)
Please use labels and text to provide additional information.
Reported by [email protected]
on 2014-08-05 21:18:05
Originally reported on Google Code with ID 4
Several tests are disabled in the nightly Kvasir tests.
Search for "medium-easy-tests" in invariants/tests/kvasir-tests/Makefile.
These should be re-enabled, and the bugs that they reveal should be fixed.
Reported by michael.ernst
on 2010-05-03 04:10:24
Originally reported on Google Code with ID 7
Daikon doesn't seem to be respecting the not_ordered flag.
For example, from the Daikon user manual:
SeqSeqIntGreaterEqual
Represents invariants between two sequences of long values. If order matters for each
variable (which it does by default), then the sequences are compared lexically. Prints
as โx[] >= y[] lexicallyโ.
If the auxiliary information (e.g., order matters) doesn't match between two variables,
then this invariant cannot apply to those variables.
I have two sequences with the not_ordered flag declared for both yet Daikon still prints
this invariant.
Attached are the .dtrace file, the resulting .invs file, the daikon-settings.txt file
that has only the SeqSeqIntGreaterEqual
Reported by melonhead901
on 2012-04-13 10:59:12
Originally reported on Google Code with ID 38
to demonstrate:
export LANG=es_ES.UTF-8 (for example - anything but US)
java -ea daikon.test.MasterUnitTester
There was 1 error:
1) testUtilMDE(plume.TestPlume)java.lang.AssertionError
at plume.TestPlume.testUtilMDE(TestPlume.java:2156)
......
TestPlume needs LC_CTYPE to be US to succeed. But we cannot just set LC_CTYPE because
if the user has set LC_ALL instead of just LANG the individual parts of locale cannot
be reset without resetting them all. I.e., the only way to override LC_ALL is to reset
LC_ALL.
Reported by [email protected]
on 2014-11-18 16:47:27
Originally reported on Google Code with ID 19
What steps will reproduce the problem?
1. javac -d bin src/com/example/RightShiftExample.java
2. java -cp daikon.jar:bin daikon.Chicory --daikon com.example.RightShiftExample
3. java -cp daikon.jar:bin daikon.tools.runtimechecker.Main instrument RightShiftExample.inv.gz
src/com/example/RightShiftExample.java
What is the expected output? What do you see instead?
Reading invariant file: RightShiftExample.inv.gz
Parsing file src/com/example/RightShiftExample.java
Instrumenting RightShiftExample.java
create(MethodDeclaration, "int signed_right_shift(int x, int y){
return x >>>>>> y;
}")
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at daikon.tools.jtb.Ast.create(Ast.java:148)
at daikon.tools.jtb.Ast.create(Ast.java:138)
at daikon.tools.jtb.Ast.copy(Ast.java:991)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:428)
at jtb.syntaxtree.MethodDeclaration.accept(MethodDeclaration.java:39)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:95)
at jtb.syntaxtree.TypeDeclaration.accept(TypeDeclaration.java:24)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:122)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
Caused by: jtb.ParseException: Parse error at line 2, column 16. Encountered: >>>
at jtb.JavaParser.generateParseException(JavaParser.java:8606)
at jtb.JavaParser.jj_consume_token(JavaParser.java:8556)
at jtb.JavaParser.UnaryExpression(JavaParser.java:2796)
at jtb.JavaParser.MultiplicativeExpression(JavaParser.java:2682)
at jtb.JavaParser.AdditiveExpression(JavaParser.java:2633)
at jtb.JavaParser.ShiftExpression(JavaParser.java:2614)
at jtb.JavaParser.RelationalExpression(JavaParser.java:2527)
at jtb.JavaParser.InstanceOfExpression(JavaParser.java:2495)
at jtb.JavaParser.EqualityExpression(JavaParser.java:2451)
at jtb.JavaParser.AndExpression(JavaParser.java:2418)
at jtb.JavaParser.ExclusiveOrExpression(JavaParser.java:2388)
at jtb.JavaParser.InclusiveOrExpression(JavaParser.java:2358)
at jtb.JavaParser.ConditionalAndExpression(JavaParser.java:2328)
at jtb.JavaParser.ConditionalOrExpression(JavaParser.java:2298)
at jtb.JavaParser.ConditionalExpression(JavaParser.java:2268)
at jtb.JavaParser.Expression(JavaParser.java:2148)
at jtb.JavaParser.ReturnStatement(JavaParser.java:4767)
at jtb.JavaParser.Statement(JavaParser.java:3797)
at jtb.JavaParser.BlockStatement(JavaParser.java:3991)
at jtb.JavaParser.Block(JavaParser.java:3926)
at jtb.JavaParser.MethodDeclaration(JavaParser.java:1312)
at jtb.JavaParser.MethodDeclaration(JavaParser.java:1270)
... 31 more
Throwable thrown while handling command:daikon.Daikon$TerminationMessage: Error in
Ast.create
daikon.Daikon$TerminationMessage: Error in Ast.create
at daikon.tools.jtb.Ast.create(Ast.java:152)
at daikon.tools.jtb.Ast.create(Ast.java:138)
at daikon.tools.jtb.Ast.copy(Ast.java:991)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:428)
at jtb.syntaxtree.MethodDeclaration.accept(MethodDeclaration.java:39)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:95)
at jtb.syntaxtree.TypeDeclaration.accept(TypeDeclaration.java:24)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:122)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
The instrumenter failed.
What version of the product are you using? On what operating system?
The revision pushed Nov 27th.
Please provide any additional information below.
The problem seems to be in the JavaCC parser. Instead of consuming the ">>" as a single
token it produces two tokens ">>" and ">".
Reported by jgaleotti
on 2013-12-04 10:32:39
java daikon.Daikon --format csharpcontract csharp-hello.dtrace.txt
produces several instances of the message:
("oneOf.java.jpp: SEQUENCE unimplemented" != null)
Originally reported on Google Code with ID 23
What steps will reproduce the problem?
1. javac -g -d bin src/com/example/ForStmt.java
2. java -cp bin:daikon.jar daikon.Chicory --daikon com.example.ForStmt
3. java -cp daikon.jar:bin daikon.tools.runtimechecker.Main instrument ForStmt.inv.gz
src/com/example/ForStmt.java
What is the expected output? What do you see instead?
Reading invariant file: ForStmt.inv.gz
Parsing file src/com/example/ForStmt.java
jtb.ParseException: Parse error at line 21, column 46. Encountered: :
at jtb.JavaParser.generateParseException(JavaParser.java:8606)
at jtb.JavaParser.jj_consume_token(JavaParser.java:8556)
at jtb.JavaParser.ForStatement(JavaParser.java:4513)
at jtb.JavaParser.Statement(JavaParser.java:3785)
at jtb.JavaParser.BlockStatement(JavaParser.java:3991)
at jtb.JavaParser.Block(JavaParser.java:3926)
at jtb.JavaParser.MethodDeclaration(JavaParser.java:1312)
at jtb.JavaParser.ClassOrInterfaceBodyDeclaration(JavaParser.java:1011)
at jtb.JavaParser.ClassOrInterfaceBody(JavaParser.java:919)
at jtb.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:529)
at jtb.JavaParser.TypeDeclaration(JavaParser.java:437)
at jtb.JavaParser.CompilationUnit(JavaParser.java:206)
at daikon.tools.jtb.ParseResults.parse(ParseResults.java:77)
at daikon.tools.jtb.ParseResults.parse(ParseResults.java:50)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:109)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
Throwable thrown while handling command:java.lang.Error: jtb.ParseException: Parse
error at line 21, column 46. Encountered: :
java.lang.Error: jtb.ParseException: Parse error at line 21, column 46. Encountered:
:
at daikon.tools.jtb.ParseResults.parse(ParseResults.java:99)
at daikon.tools.jtb.ParseResults.parse(ParseResults.java:50)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:109)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
Caused by: jtb.ParseException: Parse error at line 21, column 46. Encountered: :
at jtb.JavaParser.generateParseException(JavaParser.java:8606)
at jtb.JavaParser.jj_consume_token(JavaParser.java:8556)
at jtb.JavaParser.ForStatement(JavaParser.java:4513)
at jtb.JavaParser.Statement(JavaParser.java:3785)
at jtb.JavaParser.BlockStatement(JavaParser.java:3991)
at jtb.JavaParser.Block(JavaParser.java:3926)
at jtb.JavaParser.MethodDeclaration(JavaParser.java:1312)
at jtb.JavaParser.ClassOrInterfaceBodyDeclaration(JavaParser.java:1011)
at jtb.JavaParser.ClassOrInterfaceBody(JavaParser.java:919)
at jtb.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:529)
at jtb.JavaParser.TypeDeclaration(JavaParser.java:437)
at jtb.JavaParser.CompilationUnit(JavaParser.java:206)
at daikon.tools.jtb.ParseResults.parse(ParseResults.java:77)
... 4 more
The instrumenter failed.
What version of the product are you using? On what operating system?
Revision 27b35b7e3299 (Nov 27th) on a MAC OS
Please provide any additional information below.
I think that the problem is triggered when a "final" modifier is used in a forach enumeration.
Like:
ForStmt iterable = new ForStmt(x);
int count = 0;
for (final ForStmt myForStmt : iterable) {
count += myForStmt.getValue();
}
Reported by jgaleotti
on 2013-12-05 13:51:09
Originally reported on Google Code with ID 41
Back on Dec 16, 2014 the regression test tests/kvasir-tests/perl was disabled. There
had been an unnoticed fault for sometime that was brought to light running on Ubuntu
14.10. On Fedora 20 the runtime outputs:
MISMATCHED on exit_function! f: ..perl_run() != perl.c.S_my_exit_jump()
DetectedEntryIP: <STATIC_ADDR> - AssumedEntryIP: <STATIC_ADDR>
DetctedExitIP: <STATIC_ADDR> - AssumedExitIp: <STATIC_ADDR>
On an Ubuntu 14.10 virtual machine it traps into Valgrind and outputs:
==21608== Process terminating with default action of signal 11 (SIGSEGV)
==21608== Bad permissions for mapped region at address 0x5050005
==21608== at 0x41D164: S_gv_init_sv (gv.c:163)
==21608== by 0x41F174: Perl_gv_fetchpv (gv.c:809)
==21608== by 0x4A069E: S_sortsv_desc (pp_sort.c:1479)
==21608== by 0x4A19C6: Perl_pp_sort (pp_sort.c:1676)
==21608== by 0x41C2B0: Perl_runops_debug (dump.c:1449)
==21608== by 0x44EFB5: S_run_body (perl.c:1930)
==21608== by 0x44EA9D: perl_run (perl.c:1854)
==21608== by 0x52B62E: main (miniperlmain.c:98)
Reported by [email protected]
on 2015-01-13 23:27:37
Originally reported on Google Code with ID 32
What steps will reproduce the problem?
1. Read the sec. 4.5 of the Daikon user manual.
What is the expected output? What do you see instead?
The correct word may be "fine-grained" instead of "find-grained".
What version of the product are you using? On what operating system?
The Daikon user manual, whose source file should be doc/daikon.texinfo (at line 1911)
Please provide any additional information below.
Reported by cheng.zhang.stap
on 2014-08-05 16:26:54
Originally reported on Google Code with ID 34
Hi,
I am trying to use Daikon on a gtest1.6 unit c++ code. But it seems it is not able
to handle that. It is throwing bunch of errors while creating the trace using kvasir-dtrace:
------------------------------------------------------------
qs@ubuntu:~/work/gtest-1.6.0/make$ make
g++ -I../include -gdwarf-2 -Wall -Wextra -c ../samples/sample1.cc
g++ -I../include -gdwarf-2 -Wall -Wextra -c ../samples/sample1_unittest.cc
g++ -I../include -I.. -gdwarf-2 -Wall -Wextra -c \
../src/gtest-all.cc
g++ -I../include -I.. -gdwarf-2 -Wall -Wextra -c \
../src/gtest_main.cc
ar rv gtest_main.a gtest-all.o gtest_main.o
ar: creating gtest_main.a
a - gtest-all.o
a - gtest_main.o
g++ -I../include -gdwarf-2 -Wall -Wextra sample1.o sample1_unittest.o gtest_main.a
-o sample1_unittest -lpthread
qs@ubuntu:~/work/gtest-1.6.0/make$ ls
gtest-all.o gtest_main.a gtest_main.o Makefile sample1.o sample1_unittest sample1_unittest.o
qs@ubuntu:~/work/gtest-1.6.0/make$ kvasir-dtrace ./sample1_unittest
==12796== kvasir-5.1.6, C/C++ Language Front-End for Daikon with DynComp comparability
analysis tool.
==12796== Copyright (C) 2007-2014, University of Washington CSE PLSE Group
==12796== Using Valgrind-3.9.0.PLSE and LibVEX; rerun with -h for copyright info
==12796== Command: ./sample1_unittest
==12796==
Unexpected unnamed parameter in FormatForComparisonFailureMessage<int, int>
Unexpected unnamed parameter in IsContainerTest<int>
Unexpected unnamed parameter in DefaultPrintTo<int>
Unexpected unnamed parameter in DefaultPrintTo<int>
Unexpected unnamed parameter in operator new
Unexpected unnamed parameter in operator delete
Unexpected unnamed parameter in operator delete
Unexpected unnamed parameter in OnTestProgramStart
Unexpected unnamed parameter in OnTestIterationStart
Unexpected unnamed parameter in OnTestIterationStart
Unexpected unnamed parameter in OnEnvironmentsSetUpStart
Unexpected unnamed parameter in OnEnvironmentsSetUpEnd
Unexpected unnamed parameter in OnTestCaseStart
Unexpected unnamed parameter in OnTestStart
Unexpected unnamed parameter in OnTestPartResult
Unexpected unnamed parameter in OnTestEnd
Unexpected unnamed parameter in OnTestCaseEnd
Unexpected unnamed parameter in OnEnvironmentsTearDownStart
Unexpected unnamed parameter in OnEnvironmentsTearDownEnd
Unexpected unnamed parameter in OnTestIterationEnd
Unexpected unnamed parameter in OnTestIterationEnd
Unexpected unnamed parameter in OnTestProgramEnd
Unexpected unnamed parameter in HasOneFailure
Unexpected unnamed parameter in HasOneFailure
Unexpected unnamed parameter in HasOneFailure
Unexpected unnamed parameter in TestPropertyKeyIs
Unexpected unnamed parameter in OnTestProgramStart
Unexpected unnamed parameter in OnEnvironmentsSetUpEnd
Unexpected unnamed parameter in OnEnvironmentsTearDownEnd
Unexpected unnamed parameter in OnTestProgramEnd
Unexpected unnamed parameter in OnEnvironmentsSetUpStart
Unexpected unnamed parameter in OnEnvironmentsTearDownStart
Unexpected unnamed parameter in OnTestIterationEnd
Unexpected unnamed parameter in OnTestIterationEnd
Unexpected unnamed parameter in OnTestProgramStart
Unexpected unnamed parameter in OnTestIterationStart
Unexpected unnamed parameter in OnTestIterationEnd
Unexpected unnamed parameter in CurrentStackTrace
Unexpected unnamed parameter in CurrentStackTrace
Unexpected unnamed parameter in TestPartResult
Unexpected unnamed parameter in TestCaseNameIs
Unexpected unnamed parameter in GetCurrentOsStackTraceExceptTop
Unexpected unnamed parameter in FormatForComparisonFailureMessage<long long int, long
long int>
Unexpected unnamed parameter in _Destroy<testing::internal::ParameterizedTestCaseInfoBase**,
testing::internal::ParameterizedTestCaseInfoBase*>
Unexpected unnamed parameter in _Destroy<testing::TestPartResult*, testing::TestPartResult>
Unexpected unnamed parameter in _Destroy<testing::TestProperty*, testing::TestProperty>
Unexpected unnamed parameter in operator=
Unexpected unnamed parameter in __iterator_category<__gnu_cxx::__normal_iterator<testing::TestProperty*,
std::vector<testing::TestProperty> > >
Unexpected unnamed parameter in __find_if<__gnu_cxx::__normal_iterator<testing::TestProperty*,
std::vector<testing::TestProperty> >, testing::internal::TestPropertyKeyIs>
Unexpected unnamed parameter in TestProperty
Unexpected unnamed parameter in operator=
Unexpected unnamed parameter in _Destroy<testing::TestInfo**, testing::TestInfo*>
Unexpected unnamed parameter in _Destroy<int*, int>
Unexpected unnamed parameter in _Destroy<testing::TestEventListener**, testing::TestEventListener*>
Unexpected unnamed parameter in TraceInfo
Unexpected unnamed parameter in operator=
Unexpected unnamed parameter in _Destroy<testing::Environment**, testing::Environment*>
Unexpected unnamed parameter in _Destroy<testing::TestCase**, testing::TestCase*>
Unexpected unnamed parameter in __iterator_category<__gnu_cxx::__normal_iterator<testing::TestCase**,
std::vector<testing::TestCase*> > >
Unexpected unnamed parameter in __find_if<__gnu_cxx::__normal_iterator<testing::TestCase**,
std::vector<testing::TestCase*> >, testing::internal::TestCaseNameIs>
Unexpected unnamed parameter in _Destroy<char**, char*>
Unexpected unnamed parameter in _Destroy<std::basic_string<char>*, std::basic_string<char>
>
Unexpected unnamed parameter in _Destroy<testing::internal::TraceInfo*, testing::internal::TraceInfo>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __destroy<testing::internal::ParameterizedTestCaseInfoBase**>
Unexpected unnamed parameter in __destroy<testing::internal::ParameterizedTestCaseInfoBase**>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::TestPartResult*, testing::TestPartResult*,
testing::TestPartResult>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::TestProperty*, testing::TestProperty*,
testing::TestProperty>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __destroy<testing::TestInfo**>
Unexpected unnamed parameter in __destroy<testing::TestInfo**>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __destroy<int*>
Unexpected unnamed parameter in __destroy<int*>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::TestInfo**, testing::TestInfo**,
testing::TestInfo*>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<int*, int*, int>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __destroy<testing::TestEventListener**>
Unexpected unnamed parameter in __destroy<testing::TestEventListener**>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::TestEventListener**,
testing::TestEventListener**, testing::TestEventListener*>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::Environment**, testing::Environment**,
testing::Environment*>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::internal::TraceInfo*,
testing::internal::TraceInfo*, testing::internal::TraceInfo>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __destroy<testing::Environment**>
Unexpected unnamed parameter in __destroy<testing::Environment**>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __destroy<testing::TestCase**>
Unexpected unnamed parameter in __destroy<testing::TestCase**>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::TestCase**, testing::TestCase**,
testing::TestCase*>
Unexpected unnamed parameter in _Destroy<testing::internal::String*, testing::internal::String>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __destroy<char**>
Unexpected unnamed parameter in __destroy<char**>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<char**, char**, char*>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<std::basic_string<char>*, std::basic_string<char>*,
std::basic_string<char> >
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in __uninitialized_copy_a<__gnu_cxx::__normal_iterator<const
testing::internal::TraceInfo*, std::vector<testing::internal::TraceInfo> >, testing::internal::TraceInfo*,
testing::internal::TraceInfo>
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in __uninitialized_copy_a<testing::internal::String*,
testing::internal::String*, testing::internal::String>
Unexpected unnamed parameter in allocator<std::_Rb_tree_node<testing::internal::String>
>
Unexpected unnamed parameter in deallocate
Unexpected unnamed parameter in allocate
Unexpected unnamed parameter in IsContainerTest<long long int>
Unexpected unnamed parameter in DefaultPrintTo<long long int>
Unexpected unnamed parameter in DefaultPrintTo<long long int>
Unexpected unnamed parameter in new_allocator
kvasir: generate_fjalar_entries.c:3123 (initMemberFuncs): Assertion 'n->elt' failed.
==12796== at 0x380B93D1: ??? (in /home/qs/work/daikon/kvasir/valgrind/inst/lib/valgrind/fjalar-x86-linux)
sched status:
running_tid=0
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: [email protected]
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
qs@ubuntu:~/work/gtest-1.6.0/make$
Reported by [email protected]
on 2014-08-30 15:10:09
Originally reported on Google Code with ID 35
1) shadowing problems with class var and method var of same name
2) when need both class var and method var with some name don't generate unique names
3) daikon.test.spliter.SplitterFactorTestUpdatter needs to be corrected
Reported by [email protected]
on 2014-10-27 22:34:07
If you set:
--config_option daikon.DynamicConstants.OneOf_only=true
--config_option daikon.inv.unary.scalar.OneOfScalar.enabled=false
Daikon gets a null pointer exception on kvasir-tests/ArraysInStructTest. I see whatโs going on, but not sure best way to fix. The two options conspire so that line 1148 of DynamicConstants.java returns null:
inv = OneOfScalar.get_proto().instantiate(slice1);
The slice looks ok. If you turn off OneOf_only or turn on OneOfScalar, all works as expected.
To add an invariant to Daikon requires defining a class for the Invariant, then editing the Daikon.setup_proto_invs method to mention the new Invariant class: https://plse.cs.washington.edu/daikon/download/doc/developer.html#New-invariants
It would be nicer to add a command-line argument that gives the fully-qualified name of an invariant. Then, method Daikon.setup_proto_invs can reflectively load the class and call its get_proto() method. No other use of reflection is needed elsewhere in the daikon codebase.
A user would still need to compile the Invariant class itself, but wouldn't need to re-compile file Daikon.java (nor remake the daikon.jar file, etc.)
Originally reported on Google Code with ID 22
What steps will reproduce the problem?
1. javac -d bin -g src/com/example/InnerStatic.java
2. java -cp bin:daikon.jar daikon.Chicory --daikon com.example.InnerStatic
3. java -cp daikon.jar:bin daikon.tools.runtimechecker.Main instrument InnerStatic.inv.gz
src/com/example/InnerStatic.java
What is the expected output? What do you see instead?
create(FormalParameter, "
InnerStatic")
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at daikon.tools.jtb.Ast.create(Ast.java:148)
at daikon.tools.jtb.Ast.create(Ast.java:138)
at daikon.tools.jtb.Ast.getType(Ast.java:183)
at daikon.tools.jtb.PptNameMatcher.getUngenerifiedType(PptNameMatcher.java:106)
at daikon.tools.jtb.PptNameMatcher.typeMatch(PptNameMatcher.java:272)
at daikon.tools.jtb.PptNameMatcher.matches(PptNameMatcher.java:259)
at daikon.tools.jtb.PptNameMatcher.matches(PptNameMatcher.java:178)
at daikon.tools.jtb.PptNameMatcher.getMatchesInternal(PptNameMatcher.java:135)
at daikon.tools.jtb.PptNameMatcher.getMatches(PptNameMatcher.java:123)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:228)
at jtb.syntaxtree.ConstructorDeclaration.accept(ConstructorDeclaration.java:70)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:95)
at jtb.syntaxtree.TypeDeclaration.accept(TypeDeclaration.java:24)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:122)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
Caused by: jtb.ParseException: Parse error at line 3, column 24. Encountered: <EOF>
at jtb.JavaParser.generateParseException(JavaParser.java:8606)
at jtb.JavaParser.jj_consume_token(JavaParser.java:8556)
at jtb.JavaParser.VariableDeclaratorId(JavaParser.java:1107)
at jtb.JavaParser.FormalParameter(JavaParser.java:1452)
... 50 more
Throwable thrown while handling command:daikon.Daikon$TerminationMessage: Error in
Ast.create
daikon.Daikon$TerminationMessage: Error in Ast.create
at daikon.tools.jtb.Ast.create(Ast.java:152)
at daikon.tools.jtb.Ast.create(Ast.java:138)
at daikon.tools.jtb.Ast.getType(Ast.java:183)
at daikon.tools.jtb.PptNameMatcher.getUngenerifiedType(PptNameMatcher.java:106)
at daikon.tools.jtb.PptNameMatcher.typeMatch(PptNameMatcher.java:272)
at daikon.tools.jtb.PptNameMatcher.matches(PptNameMatcher.java:259)
at daikon.tools.jtb.PptNameMatcher.matches(PptNameMatcher.java:178)
at daikon.tools.jtb.PptNameMatcher.getMatchesInternal(PptNameMatcher.java:135)
at daikon.tools.jtb.PptNameMatcher.getMatches(PptNameMatcher.java:123)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:228)
at jtb.syntaxtree.ConstructorDeclaration.accept(ConstructorDeclaration.java:70)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:95)
at jtb.syntaxtree.TypeDeclaration.accept(TypeDeclaration.java:24)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:122)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
The instrumenter failed.
What version of the product are you using? On what operating system?
Revision 27b35b7e3299
Host: MAC OS X
Please provide any additional information below.
I think the problem is a typo in method daikon.tools.jtb.Ast.getParameters(ConstructorDeclaration).
In particular, the implicit outer class parameter should be passed only when the inner
class is non-static.
Reported by jgaleotti
on 2013-12-05 10:18:37
Originally reported on Google Code with ID 11
What steps will reproduce the problem?
1. Run Chicory on the attached program.
What is the expected output? What do you see instead?
The output dtrace file should have the linked list treated as a vector. For example,
there should be a variable arg0[..] entry in ppt HelloWorld.print(LNode):::ENTER. Instead
no vectorization is seen
What version of the product are you using? On what operating system?
Java 1.7.0_07, Daikon 4.6.4, Win7 under cygwin
Please provide any additional information below.
Reported by melonhead901
on 2013-06-04 11:25:00
Originally reported on Google Code with ID 20
What steps will reproduce the problem?
1. javac -d bin/ -g src/com/example/PowerOfTwo.java
2. java -cp bin/:daikon.jar daikon.Chicory --daikon com.example.PowerOfTwo
3. java -cp daikon.jar:bin daikon.tools.runtimechecker.Main instrument PowerOfTwo.inv.gz
src/com/example/PowerOfTwo.java
What is the expected output? What do you see instead?
Reading invariant file: PowerOfTwo.inv.gz
Parsing file src/com/example/PowerOfTwo.java
Instrumenting PowerOfTwo.java
create(Block, "{daikon.tools.runtimechecker.Runtime.numPptEntries++;checkClassInvariantsInstrument(daikon.tools.runtimechecker.Violation.Time.onEntry);try
{
daikon.tools.runtimechecker.Runtime.numEvaluations++;if (!(
x is a power of 2)) {daikon.tools.runtimechecker.Runtime.violationsAdd(daikon.tools.runtimechecker.Violation.get(daikonProperties[4],
daikon.tools.runtimechecker.Violation.Time.onEntry));}} catch (ThreadDeath t_instrument)
{
throw t_instrument;} catch (Throwable t_instrument) {
}boolean methodThrewSomething_instrument = false;boolean retval_instrument = false;retval_instrument
= internal$watchMe(x);daikon.tools.runtimechecker.Runtime.numNormalPptExits++;try {
daikon.tools.runtimechecker.Runtime.numEvaluations++;if (!(
retval_instrument == false)) {daikon.tools.runtimechecker.Runtime.violationsAdd(daikon.tools.runtimechecker.Violation.get(daikonProperties[5],
daikon.tools.runtimechecker.Violation.Time.onExit));}} catch (ThreadDeath t_instrument)
{
throw t_instrument;} catch (Throwable t_instrument) {
}checkClassInvariantsInstrument(daikon.tools.runtimechecker.Violation.Time.onExit);return
retval_instrument;}")
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at daikon.tools.jtb.Ast.create(Ast.java:148)
at daikon.tools.jtb.Ast.create(Ast.java:138)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:431)
at jtb.syntaxtree.MethodDeclaration.accept(MethodDeclaration.java:39)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:95)
at jtb.syntaxtree.TypeDeclaration.accept(TypeDeclaration.java:24)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:122)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
Caused by: jtb.ParseException: Parse error at line 3, column 3. Encountered: is
at jtb.JavaParser.generateParseException(JavaParser.java:8606)
at jtb.JavaParser.jj_consume_token(JavaParser.java:8556)
at jtb.JavaParser.PrimaryPrefix(JavaParser.java:3219)
at jtb.JavaParser.PrimaryExpression(JavaParser.java:3126)
at jtb.JavaParser.PostfixExpression(JavaParser.java:3040)
at jtb.JavaParser.UnaryExpressionNotPlusMinus(JavaParser.java:2887)
at jtb.JavaParser.UnaryExpression(JavaParser.java:2792)
at jtb.JavaParser.UnaryExpressionNotPlusMinus(JavaParser.java:2856)
at jtb.JavaParser.UnaryExpression(JavaParser.java:2792)
at jtb.JavaParser.MultiplicativeExpression(JavaParser.java:2682)
at jtb.JavaParser.AdditiveExpression(JavaParser.java:2633)
at jtb.JavaParser.ShiftExpression(JavaParser.java:2586)
at jtb.JavaParser.RelationalExpression(JavaParser.java:2527)
at jtb.JavaParser.InstanceOfExpression(JavaParser.java:2495)
at jtb.JavaParser.EqualityExpression(JavaParser.java:2451)
at jtb.JavaParser.AndExpression(JavaParser.java:2418)
at jtb.JavaParser.ExclusiveOrExpression(JavaParser.java:2388)
at jtb.JavaParser.InclusiveOrExpression(JavaParser.java:2358)
at jtb.JavaParser.ConditionalAndExpression(JavaParser.java:2328)
at jtb.JavaParser.ConditionalOrExpression(JavaParser.java:2298)
at jtb.JavaParser.ConditionalExpression(JavaParser.java:2268)
at jtb.JavaParser.Expression(JavaParser.java:2148)
at jtb.JavaParser.IfStatement(JavaParser.java:4338)
at jtb.JavaParser.Statement(JavaParser.java:3773)
at jtb.JavaParser.BlockStatement(JavaParser.java:3991)
at jtb.JavaParser.Block(JavaParser.java:3926)
at jtb.JavaParser.TryStatement(JavaParser.java:4836)
at jtb.JavaParser.Statement(JavaParser.java:3809)
at jtb.JavaParser.BlockStatement(JavaParser.java:3991)
at jtb.JavaParser.Block(JavaParser.java:3926)
... 30 more
Throwable thrown while handling command:daikon.Daikon$TerminationMessage: Error in
Ast.create
daikon.Daikon$TerminationMessage: Error in Ast.create
at daikon.tools.jtb.Ast.create(Ast.java:152)
at daikon.tools.jtb.Ast.create(Ast.java:138)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:431)
at jtb.syntaxtree.MethodDeclaration.accept(MethodDeclaration.java:39)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:226)
at jtb.syntaxtree.ClassOrInterfaceBodyDeclaration.accept(ClassOrInterfaceBodyDeclaration.java:25)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:25)
at jtb.syntaxtree.NodeListOptional.accept(NodeListOptional.java:34)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:216)
at daikon.tools.runtimechecker.InstrumentVisitor.visit(InstrumentVisitor.java:170)
at jtb.syntaxtree.ClassOrInterfaceBody.accept(ClassOrInterfaceBody.java:40)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:112)
at jtb.syntaxtree.ClassOrInterfaceDeclaration.accept(ClassOrInterfaceDeclaration.java:43)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:35)
at jtb.syntaxtree.NodeSequence.accept(NodeSequence.java:34)
at jtb.syntaxtree.NodeChoice.accept(NodeChoice.java:24)
at jtb.visitor.DepthFirstVisitor.visit(DepthFirstVisitor.java:95)
at jtb.syntaxtree.TypeDeclaration.accept(TypeDeclaration.java:24)
at daikon.tools.runtimechecker.InstrumentHandler.handle(InstrumentHandler.java:122)
at daikon.tools.runtimechecker.Main.nonStaticMain(Main.java:45)
at daikon.tools.runtimechecker.Main.main(Main.java:71)
The instrumenter failed.
What version of the product are you using? On what operating system?
Revision: 27b35b7e3299
Please provide any additional information below.
The string output by daikon.inv.unary.scalar.RangeInt.PowerOfTwo.get_format_str(OutputFormat)
does not consider a potential Java runtime check.
A possible fix could be to add the following case, and include daikon.Quant.powerOfTwo
to daikon.Quant:
public String get_format_str(OutputFormat format) {
if (format == OutputFormat.SIMPLIFY)
return ("(EXISTS (p) (EQ %var1% (pow 2 p)))");
else if (format == OutputFormat.JAVA) {
return ("daikon.Quant.powerOfTwo(%var1%)");
} else
return ("%var1% is a power of 2");
}
Reported by jgaleotti
on 2013-12-04 14:53:18
Hi, everyone.
I found a problem with daikon. The tests failed for a clean daikon from git.
They just crashed for the same reason.
This is one of the tests that failed. It seems that the code is not correctly initialized.
$/daikon/tests/kvasir-tests/TypesTest$ /home/canicula/work/daikon-5.3.0/scripts/kvasir-dtrace --decls-file=daikon-output/TypesTest.decls ./TypesTest >TypesTest.out 2>&1
System information:
daikon/tests/kvasir-tests/TypesTest$ uname -a
Linux 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:26:47 UTC 2016 i686 i686 i686 GNU/Linux
/daikon/tests/kvasir-tests/TypesTest$ cat /etc/issue
Ubuntu 14.04.4 LTS \n \l
/daikon/tests/kvasir-tests/TypesTest$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
Error information:
==29347== kvasir-5.3.0, C/C++ Language Front-End for Daikon with DynComp comparability analysis tool.
==29347== Copyright (C) 2007-2016, University of Washington CSE PLSE Group
==29347== Using Valgrind-3.11.0.Fjalar and LibVEX; rerun with -h for copyright info
==29347== Command: ./TypesTest
==29347==
kvasir: fjalar_main.h:127 (fnStackTop): Assertion 'fn_stack_first_free_index[tid] >= 0' failed.
host stacktrace:
==29347== at 0x380B0866: show_sched_status_wrk (m_libcassert.c:343)
==29347== by 0x380B09A6: report_and_quit (m_libcassert.c:415)
==29347== by 0x380B0ACB: vgPlain_assert_fail (m_libcassert.c:481)
==29347== by 0x3800CB02: fnStackTop (fjalar_main.h:127)
==29347== by 0x38011E3F: mc_new_mem_stack_4 (mc_main.c:3030)
==29347== by 0x6478F038: ???
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 29347)
==29347== at 0x40010D2: ??? (in /lib/i386-linux-gnu/ld-2.19.so)
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: [email protected]
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
Originally reported on Google Code with ID 37
Now that kvasir-tests/gtest is working with Fjalar/Kvasir (see issue #34) it looks like
there is a problem processing the output in daikon. Don't know if kvasir output is
incorrect or daikon interpretation is incorrect, but problem is that diakon reports
duplicate symbol definitions. In daikon/tests/kvasir-tests/gtest run diffs-w-daikon
to see problem. EXCEPT that kvasir-tests/Makefile.common is currently hacked to not
run test case. See notes in this file to turn back on.
Reported by [email protected]
on 2014-11-18 04:54:24
Originally reported on Google Code with ID 28
Hi,
I am trying to use Daikon on a very simple c++ code. But it seems it is not able to
handle that. It is throwing bunch of errors while creating the trace using kvasir-dtrace:
Unexpected unnamed parameter in operator new
Unexpected unnamed parameter in operator++
Unexpected unnamed parameter in __iterator_category<std::_List_const_iterator<int>
>
.....
kvasir: generate_fjalar_entries.c:3111 (initMemberFuncs): Assertion 'n->elt' failed.
==52992== at 0x380A6F07: ??? (in /g/g90/mitra3/work/DIKON/fjalar/valgrind/inst/lib/valgrind/fjalar-amd64-linux)
I will highly appreciate any kind of help.
Following is my simple test code:
#include<list>
#include<iostream>
using namespace std;
int getAvg(list<int> & arr)
{
list<int>::iterator beg = arr.begin(), end = arr.end();
int sum = 0;
for(; beg != end; beg++)
{
sum += (*beg);
}
cout << sum << endl;
return sum/arr.size();
}
int main()
{
list<int> a;
a.push_back(10);
a.push_back(20);
a.push_back(30);
a.push_back(40);
a.push_back(50);
a.push_back(60);
int avg = getAvg(a);
cout << avg << endl;
return 0;
}
This is how I am compiling: g++ -g -O0 -gdwarf-2 test.cpp
Thanks,
Subrata
Reported by [email protected]
on 2014-02-27 19:54:57
Repro steps (following steps in Daikon User Manual "2.2.2 Unix/Linux/MacOSX installation" at https://github.com/codespecs/daikon/blob/master/doc/daikon.texinfo#L406):
daikon-5.3.8.tar.gz
package into directoryDAIKONDIR
and JAVA_HOME
environment variablesscripts/daikon.bashrc
make
command:make -C $DAIKONDIR rebuild-everything
Make fails due to missing etags
program with following output:
make: Entering directory `/home/rcook/daikon-5.3.8'
make -C /home/rcook/daikon-5.3.8 rebuild-everything-but-kvasir
make[1]: Entering directory `/home/rcook/daikon-5.3.8'
make -C /home/rcook/daikon-5.3.8/java tags compile
make[2]: Entering directory `/home/rcook/daikon-5.3.8/java'
Makefile:749: *** etags is not available, please install it. Stop.
make[2]: Leaving directory `/home/rcook/daikon-5.3.8/java'
make[1]: *** [rebuild-everything-but-kvasir] Error 2
make[1]: Leaving directory `/home/rcook/daikon-5.3.8'
make: *** [rebuild-everything] Error 2
make: Leaving directory `/home/rcook/daikon-5.3.8'
See https://github.com/codespecs/daikon/blob/master/java/Makefile#L749. This reproduces on my Centos 7 machine.
I'm guessing that etags
is an Emacs-related program. I am not an Emacs user so I don't have it. Is there a straightforward way to install this program? Is this dependency on Emacs intentional? Perhaps the documentation should be updated to explain this step.
Originally reported on Google Code with ID 21
What steps will reproduce the problem?
1. javac -g -d bin src/com/example/InnerNonStatic.java
2. java -cp bin:daikon.jar daikon.Chicory --daikon com.example.InnerNonStatic
What is the expected output? What do you see instead?
Executing target program: java -cp bin:daikon.jar -ea -Xmx1000m -javaagent:daikon.jar=--daikon
--dtrace-file=InnerNonStatic.dtrace.gz com.example.InnerNonStatic
entered daikon.chicory.Runtime.setDtrace(./InnerNonStatic.dtrace.gz, false)...
Exception in thread "main" java.lang.VerifyError: Instruction type does not match stack
map in method com.example.InnerNonStatic$MyInnerCNhoicnoSrty awatrincin.g<:i nnoi rte>co(rLdcs
owemr/e epxrianmtepdl
e/InnerNonStatic;)V at offset 10
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2308)
at java.lang.Class.getDeclaredFields(Class.java:1760)
at daikon.chicory.DaikonVariableInfo.addClassVars(DaikonVariableInfo.java:478)
at daikon.chicory.DaikonVariableInfo.addChildNodes(DaikonVariableInfo.java:1250)
at daikon.chicory.RootInfo.exit_process(RootInfo.java:115)
at daikon.chicory.Runtime.process_new_classes(Runtime.java:441)
at daikon.chicory.Runtime.enter(Runtime.java:244)
at com.example.InnerNonStatic.main(InnerNonStatic.java:32)
Warning: Did not run Daikon because target exited with 1 status
What version of the product are you using? On what operating system?
Revision 27b35b7e3299
Please provide any additional information below.
Reported by jgaleotti
on 2013-12-05 10:11:57
Chicory's method Instrument.addInvokeToClinit
calls call_initNotify
. However, the call to call_initNotify
looks like dead code, and it looks like it has been dead code since it was added in 2005. What is addInvokeToClinit
really trying to do? Should we remove the call, or should we use its result?
Also in method addInvokeToClinit, the line
InstructionList newList = mg.getInstructionList();
looks extraneous too.
Originally reported on Google Code with ID 26
If you cd to tests/daikon-tests/RatPoly; then do:
make clean
make dyndomp-diff
The four output files:
RatPoly.txt-cset
RatPoly.txt-cset.diff
RatPoly.decls-DynComp
RatPoly.decls-DynComp.diff
show many differences. We looked at one in particular from RatPoly.txt-cset.diff:
Variable sets for PolyCalc.RatPoly.findTermIndex(PolyCalc.RatTermVec ts, I expt) exit
- [1] [Parameter expt]
- [1] [return]
+ [2] [Parameter expt, return]
[1] [Parameter ts]
[1] [Field ts.wrapped]
[1] [List ts.wrapped[..]]
[1] [Class of ts.wrapped[..]]
We didn't think that Parameter expt and return should be in the same set.
Reported by [email protected]
on 2014-02-05 17:08:03
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.