Coder Social home page Coder Social logo

codespecs / daikon Goto Github PK

View Code? Open in Web Editor NEW
208.0 7.0 54.0 841.42 MB

Dynamic detection of likely invariants

Home Page: http://plse.cs.washington.edu/daikon/

License: Other

Makefile 2.01% C 41.26% Java 23.25% Perl 1.78% HTML 0.15% Common Lisp 0.01% BlitzBasic 12.59% Shell 1.71% Python 0.20% PHP 0.05% Batchfile 0.01% Scilab 0.54% C++ 15.99% SAS 0.06% Smalltalk 0.02% Assembly 0.03% Module Management System 0.06% DIGITAL Command Language 0.04% Pascal 0.21% CLIPS 0.03%
c java perl csharp eiffel machine-learning machinelearning specif specification-by-example specifications

daikon's People

Contributors

agarciadom avatar bdemsky avatar calvin-l avatar davidcok avatar emspishak avatar flgr avatar jonathanburke avatar jthaine avatar jwnimmer avatar jyoo980 avatar kelloggm avatar konne88 avatar markro49 avatar mdernsta avatar mernst avatar mmenarini avatar msridhar avatar natelevin1 avatar smillst avatar solleks avatar vhellendoorn avatar wmdietl avatar xingweitian avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

daikon's Issues

bad instrumentation for nested <init> methods?

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

Runtime check instrumentation fail for EltOneOf invariant

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


- _Attachment: [daikon_bug1.zip](https://storage.googleapis.com/google-code-attachments/daikon/issue-17/comment-0/daikon_bug1.zip)_

java.util.zip.zipexception error in opening zip file

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

Instructions for rebuilding Daikon with C/C++ front end results in error due to missing "etags" program

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

  • Download and extract daikon-5.3.8.tar.gz package into directory
  • Set DAIKONDIR and JAVA_HOME environment variables
  • Source scripts/daikon.bashrc
  • Run following 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.

confusion with boolean as rep_type

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


- _Attachment: [test.java](https://storage.googleapis.com/google-code-attachments/daikon/issue-33/comment-0/test.java)_

RuntimeChecker crashes instrumenting inner classes with multiple constructors

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


- _Attachment: [daikon_bug8.zip](https://storage.googleapis.com/google-code-attachments/daikon/issue-22/comment-0/daikon_bug8.zip)_

Daikon.Daikon crashes in presence of shutdown hooks

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

LinkedLists doesn't seem to be working

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


- _Attachment: [HelloWorld.java](https://storage.googleapis.com/google-code-attachments/daikon/issue-11/comment-0/HelloWorld.java)_

ksavir compile error on redhat linux

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


- _Attachment: [daikon_kvasir_compile_failure.txt](https://storage.googleapis.com/google-code-attachments/daikon/issue-25/comment-0/daikon_kvasir_compile_failure.txt)_

instrumentation of runtime checks fails while parsing right shifts (signed and unsigned)

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


- _Attachment: [daikon_bug4.zip](https://storage.googleapis.com/google-code-attachments/daikon/issue-19/comment-0/daikon_bug4.zip)_

Incorrect contracts involving derived array splices (C# format)

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


- _Attachment: [QueueAr.txt-csharpcontract.diff](https://storage.googleapis.com/google-code-attachments/daikon/issue-44/comment-0/QueueAr.txt-csharpcontract.diff)_

conflicting OneOf invariant options causes null pointer exception

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.

DynComp doesn't work with Java 7

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

Daikon filter (--ppt-select-pattern) with frequent exceptions and no invariants out

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)

Fault if try to instrument method with lots of arguments

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

Daikon doesn't respect not_ordered flag

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

Security managers causes invalid dtrace (or daikon analysis)

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

is ./Makefile-dist needed?

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

Locale problem with MasterUnitTester

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

BuildJDK needs to flush its ouput file

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

Disabled Kvasir test: povray

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

perl testcase is disabled

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

instrumentation of runtime checks fails for power of two invariants

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


- _Attachment: [daikon_bug5.zip](https://storage.googleapis.com/google-code-attachments/daikon/issue-20/comment-0/daikon_bug5.zip)_

RuntimeChecker crashes when foreach variable has a final modifier

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


- _Attachment: [daikon_bug9.zip](https://storage.googleapis.com/google-code-attachments/daikon/issue-23/comment-0/daikon_bug9.zip)_

Rename command-line arguments for DynComp for C

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

Tests failing post-merge with main Daikon tree (C# format)

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


- _Attachment: [test_summary.txt](https://storage.googleapis.com/google-code-attachments/daikon/issue-43/comment-0/test_summary.txt)_

Patch for /scripts/dtrace-count.pl

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


- _Attachment: [dtrace-count.pl.patch](https://storage.googleapis.com/google-code-attachments/daikon/issue-31/comment-0/dtrace-count.pl.patch)_

Dead code in addInvokeToClinit

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.

Can't merge multiple dyncomp runs

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

Crash: kvasir: fjalar_main.h:127 (fnStackTop): Assertion 'fn_stack_first_free_index[tid] >= 0' failed.

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.

fjalar problem with c++ template classes?

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

kvasir-dtrace failure for gtest1.6

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

Can not define max heap size

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

Daikon signals VerifyError in presence of non-static inner classes

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


- _Attachment: [daikon_bug7.zip](https://storage.googleapis.com/google-code-attachments/daikon/issue-21/comment-0/daikon_bug7.zip)_

Minor typo in the Daikon user manual

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

DynComp failures with tests/daikon-tests/RatPoly

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

Command-line argument for specifying user-defined invariants

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

Additional formatting options

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

instrumentation of runtime checks creates a body for abstract classes

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


- _Attachment: [daikon_bug2.zip](https://storage.googleapis.com/google-code-attachments/daikon/issue-18/comment-0/daikon_bug2.zip)_

Daikon failure on gtest

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

dcomp_rt NullPointerException when built with Oracle jdk1.7.0_21 on Mac OS 10.7.5

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


- _Attachment: [BuildJDK.java](https://storage.googleapis.com/google-code-attachments/daikon/issue-9/comment-0/BuildJDK.java)_

make fails on OS X

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

Chicory Crashes

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


- _Attachment: [HelloWorld.java](https://storage.googleapis.com/google-code-attachments/daikon/issue-10/comment-0/HelloWorld.java)_

More work needs to be done on splitter

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

Need to add support for Java8

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.