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

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

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

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.

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'

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.

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.

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)

*/

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.

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.

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

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.

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

diff with X86 about whether a location is STATIC or STACK.  need to investigate

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.

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

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.

doesn't seem very useful; refers to non existent directory (bin); and does not appear
to be mentioned in documentation.

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.

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.

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.

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)

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");
        }

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();
        }

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.

This doesn't appear to be true for default Fedora or Ubantu

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.

        InstructionList newList = mg.getInstructionList();

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

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) 

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

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

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$

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

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.

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.

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.

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

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)

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.

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.

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

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.

several references to /afs/csail.mit.edu at top of file

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

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.