[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter gives solutions for certain problems you might have with Daikon. It also tells you how to report bugs in a useful manner.
If, after reading this section and other parts of the manual, you are unable to solve your problem, you may wish to send mail to one of the mailing lists (see section Mailing lists).
9.1 Problems running Daikon | ||
9.2 Large data trace (.dtrace) files | ||
9.3 Parsing Java 5.0 code | ||
9.4 Problems with Chicory | ||
9.5 Reporting problems | ||
9.6 Known bugs | ||
9.7 Further reading |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You may find the debugging flags ‘--debug’ and ‘--dbg category’ useful if you wish to track down bugs or better understand Daikon’s operation; See section Daikon debugging options. See section Configuration options, for another way to adjust Daikon’s output.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you can’t run Daikon at all and you get an error such as
Exception in thread "main" java.lang.NoClassDefFoundError: daikon/Chicory |
then you have not put ‘daikon.jar’ on your classpath; see section Simple installation instructions.
More generally, an error such as
Exception in thread "main" java.lang.NoClassDefFoundError: plume/FuzzyFloat |
means that Java did not find the class ‘plume/FuzzyFloat’ on your classpath. To debug such a problem, you need to determine your classpath (it’s your ‘CLASSPATH’ environment variable under Mac/Linux), and the location of file ‘plume/FuzzyFloat.class’ or of the jar file that contains it.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Sometimes, Daikon may produce a very large number of seemingly irrelevant properties that obscure the facts that you were hoping to see. Which properties are irrelevant depends on your current task, so Daikon provides ways for you to customize its output. See Daikon’s command-line options (see section Running Daikon), and the techniques for enhancing its output (see section Enhancing Daikon output), including its configuration options (see section Configuration options). The options for the front ends — such as Chicory (see section Chicory options) and Kvasir (see section Kvasir options) — give additional control.
Some irrelevant properties are over unrelated variables, like comparing an array index to elements of the array. You should always use the DynComp tool (see DynComp dynamic comparability (abstract type) analysis for Java, DynComp dynamic comparability (abstract type) analysis for C/C++) to avoid producing such properties.
Some irrelevant properties are not relevant to the domain (e.g., bitwise operations). You can exclude whole classes of unhelpful invariants from Daikon’s output (see section Options to enable/disable specific invariants).
Some irrelevant properties are over variables you do not care about, or are in parts of the program that you do not care about. You can exclude certain variables or procedures from Daikon’s output (see Processing only part of the trace file and Options to enable/disable derived variables).
Some irrelevant properties are logically redundant — multiple properties express the same facts in different ways. You can eliminate such properties from Daikon’s output (see section Options to control invariant detection).
Some irrelevant output indicates a deficiency in your test suite: your test suite is so small that many arbitrary properties hold over it. This happens when the test suite does not execute the code with a broad distribution of values, but only executes the code with a few specific values. This problem disappears if you augment your test suite so that it exercises the code with more different values.
More generally, each property that Daikon produces is a true fact about how the target program behaved. However, some of these facts would be true for any execution of the target program, and others are accidents of the particular executions that Daikon observed. Both types of facts may be useful: the former tell you about your program, and the latter tell you about your test suite (and how to improve it!).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Daikon may sometimes fail to output invariants that you expect it to output. Here are some reasons why this may happen:
There are two command-line options (‘--disc_reason’ and ‘--track’) that will display information about invariants that are not printed. The ‘--disc_reason’ option will indicate why a particular invariant was discarded in most cases. If it does not provide enough information, try the ‘--track’ option which traces the invariant through all of Daikon’s processing steps. See Daikon debugging options for more information.
Note that in each case the description (class, variables, program point) of the invariant must be entered carefully. It may be helpful to try the option on a similar invariant that is printed to make sure that each is specified correctly.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Sometimes, Daikon does not report an invariant, even though Daikon has computed that the invariant is true throughout the sample data. Daikon only reports invariants that satisfy all the output filters (see section Invariant filters).
Here, we discuss two common reasons for filtering: statistical justification, and implication.
Daikon only reports a property if it is statistically justified, and Daikon needs to see enough samples for the statistical test to work. So, there may be a property that is true, but if too few samples were seen, then Daikon will not report it. In a longer trace, Daikon would report the property. You can adjust Daikon’s confidence limit so that the property is reported even in the short executions; see the command-line option ‘--conf_limit’. For instance, supplying ‘--conf_limit 0’ causes all properties that have not been falsified to be printed.
Daikon does not report redundant, or implied, invariants (see section Redundant invariants). The purpose of this is to avoid cluttering the output with facts that add no new information. Here are a few examples:
i < j
and
i <= j
are true. Daikon would report
only i < j
; Daikon would not report i <= j
, which is
implied by what Daikon has reported. Further suppose that a longer
execution had a sample containing i=22, j=22
. Only i <= j
would be true in the second execution, and Daikon would report it.
(The invariant i < j
is an example of a false positive or
overfitting in the first execution.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When Daikon produces no output, that is usually a result of it having no samples from which to generalize. Use the ‘--output_num_samples’ flag to Daikon to find out how many samples it is observing. This section tells you how to debug your problem if the answer is 0, but you believe that there are samples in the file you are feeding to Daikon.
Using the normal dataflow hierarchy, Daikon only explicitly processes
:::EXIT
program points. Other program points, such as
:::ENTER
program points, are processed indirectly when their
corresponding :::EXIT
points are encountered.
(You can disable this behavior with the
‘--nohierarchy’ switch to Daikon;
see See section Options to control invariant detection.)
If no :::EXIT
program points are present (perhaps every
execution threw an exception, you filtered out all the
:::EXIT
program points, or the data trace is obtained from
spreadsheet data instead of from a program execution),
then Daikon will not process any of the other program points, such as
the :::ENTER
program points. You can make Daikon print information
about unmatched procedure entries
via the ‘daikon.FileIO.unmatched_procedure_entries_quiet’
configuration option (see section General configuration options).
Another way to increase the number of invariants printed out is to lower the confidence bound cutoff. Daikon only prints invariants whose confidence level is greater than the bound specified by the ‘--conf_limit’ option (see section Options to control invariant detection). In order to maximize the number of invariants printed, use ‘--conf_limit 0’ to see all invariants Daikon is considering printing.
To try to determine why an invariant is not printed, use the ‘--track’ to determine why Daikon does not print an invariant (see section Daikon debugging options).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Daikon sometimes issues a warning that a procedure in the target program was entered but never exited (that is, the target program abnormally terminated). In other words, the ‘.dtrace’ file contains more entry records than exit records for the given procedure. Some procedures that were entered were never recorded to have exited: either they threw an exception, skipping the instrumentation code that would have recorded normal termination, or the target program’s run was interrupted. When this happens, the entry sample is ignored; the rationale is that the particular values seen led to exception exit, were probably illegal, and so should not be factored into the method preconditions.
In some cases, exceptional exit from a procedure can cause procedure
entries and exits (in the trace file) to be incorrectly matched up; if
they are incorrectly matched, then the orig(x)
values may
be incorrect. Daikon has two techniques for associate procedure exits
with entries — the nonce technique and the stack technique. If a
‘.dtrace’ file uses the nonce technique, orig(x)
values are guaranteed to be correct. If a ‘.dtrace’ file uses
the stack technique, then incorrect orig(x)
values are
likely to occur. You can tell which technique Daikon will use by
examining the ‘.dtrace’ file. If the second line of each entry
in the ‘.dtrace’ file is ‘this_invocation_nonce’, then Daikon
uses the nonce technique. Otherwise, it uses the stack technique.
Which technique is used is determined by the front end, which creates
the ‘.dtrace’ file, and typically cannot be controlled by the
user.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Daikon requires a Java 5 JVM (see section Requirements for running Daikon). An error such as
Exception in thread "main" java.lang.UnsupportedClassVersionError: daikon/Daikon (Unsupported major.minor version 49.0) |
indicates that you are trying to run Daikon on an older JVM. You need to install a newer version of Java in order to run Daikon.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If Daikon runs out of memory, generating a message like
Exception in thread "main" java.lang.OutOfMemoryError <<no stack trace available>> |
then it is likely that it has created more invariants than will fit
in memory. The number of invariants created depends on the number of
program points and the number of variables at each program point.
In addition to the solutions discussed in Reducing program points (functions),
you can try increasing the amount of memory available to Java
with the ‘-Xmx’ argument to java
. (This flag is
JVM-specific; see your JVM documentation for details. For instance,
its name in JDK versions 1.2 and earlier is ‘-mx’.)
However, the value you use should be less your system’s total amount
of physical memory.
The default may be 64 megabytes or less; to permit use of up to 256
megabytes, you would run Java like so:
java -Xmx256m ... |
If you are using Chicory’s ‘--daikon’ command-line argument to run Daikon, then you must separately indicate the amount of memory available to Chicory and to Daikon (the latter with Chicory’s ‘--heap-size’ command-line argument). For example:
java -Xmx256m daikon.Chicory --daikon --heap-size=1600m \ mypackage.MyClass arg1 arg2 arg3 |
When using the Java HotSpot JVM, an additional parameter may need to be increased. HotSpot uses a separately-limited memory region, called the “permanent generation”, for several special kinds of allocation, one of which (interned strings) Daikon sometimes uses heavily. It may be necessary to increase this limit as well, with the ‘-XX:MaxPermSize=’ option. For instance, to use 512 megabytes, of which at most 256 can be used for the permanent generation, you would run Java like so:
java -Xmx512m -XX:MaxPermSize=256m |
Another possible problem is the creation of too many derived variables. If you supply the ‘--output_num_samples’ option to Daikon (see section Options to control Daikon output), then it will list all variables at each program point. If some of these are of no interest, you may wish to suppress their creation. For information on how to do that, see Options to enable/disable derived variables. Also see Reducing variables for other techniques.
Any output generated before the out-of-memory error is perfectly valid.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The warning “Could not utilize Simplify” indicates that the Simplify theorem-prover could not be run; this usually indicates that the Simplify binary was not found on the user’s path. Simplify must be separately obtained (from http://www.hpl.hp.com/downloads/crl/jtk/) and installed.
If Simplify is not used, certain redundant (logically implied) invariants may appear in Daikon’s output. The output is correct, but more verbose than it would be if you used Simplify.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The invariants Daikon produces are all true statements about the supplied program executions, so they should be mutually consistent. Sometimes, however, because of a bug or a limitation in Daikon, contradictory invariants are produced.
One known problem involves object invariants. Daikon infers object invariants by observing the state of an object when its public methods are called. However, if an object has publicly accessible fields that are changed by code outside the class, after which no public methods are called, invariants about the state of the object as seen by other code can contradict the class’s object invariants. A workaround is to allow changes to an object’s state from outside the class only by way of public methods.
Besides confusing the user, contradictory invariants also cause trouble for the Simplify theorem prover that implements the ‘--suppress_redundant’ option. When the invariants at a particular program point contradict each other or background information (such as the types of objects), Simplify becomes unable to distinguish redundant invariants from non-redundant ones.
The best solution in such cases is to fix the underlying cause of the contradictory invariants, but since that is sometimes not possible, Daikon will try to work around the problem by avoiding the invariants that cause a contradiction. Daikon will attempt to find a small subset of the invariants that aren’t mutually consistent, and remove one, repeating this process until the remaining invariants are consistent. (Note that the invariants are removed only for the purposes of processing by Simplify; this does not affect whether they will be printed in the final output). While this technique can allow redundant invariants to be found when they otherwise wouldn’t be, it has some drawbacks: the choice of which invariant to remove is somewhat arbitrary, and the process of finding contradictory subsets can be time consuming. The removal process can be disabled with the ‘daikon.simplify.LemmaStack.remove_contradictions’ configuration option.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Daikon may produce output like the following (but all on one line):
method daikon.inv.binary.twoSequence.SubSequence.format_esc() needs to be implemented: this.theArray[0..this.topOfStack] is a subsequence of orig(this.theArray[0..this.topOfStack]) |
This indicates that a particular invariant (shown on the last two lines above) cannot be formatted using the current formatting. In this example, the invariant can be formatted using Daikon’s default formatting (which is how it is shown above), but (as of April 2002) Daikon cannot output it in ESC format, so Daikon prints the above message instead. The message also shows exactly what Java method needs to be implemented to correct the problem. You can ignore such messages, or else use an output formatting that can handle those invariants. Annotate (see section Annotate) automatically ignores unformattable invariants.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
It can sometimes be slow to create a trace for Daikon to analyze, and it can be slow for Daikon to analyze that trace.
If Daikon runs too slowly, the problem may be that Daikon is spending too much time collecting, then outputting, large amounts of data about your program execution.
For additional details on improving Daikon’s performance, see Out of memory, and Large data trace (.dtrace) files.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Creating a trace can take a long time, because of the time to traverse and print the values of many variables. If your invariant detection process runs slowly, you might want to separate the creation and analysis of the trace file, to help you understand which part (or both) are at fault. Reducing the number of program points or variables can speed up both creation and analysis of trace files. For instance, you might eliminate helper procedures from the analysis, or eliminate large arrays that get repeatedly output.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Daikon’s runtime and space depend on the particular data that it analyzes. Informally, invariant detection time can be characterized as
O((vars^3 * falsetime + trueinvs * testsuite) * procedures) |
where vars is the number of variables at a program point, falsetime is the (small constant) time to falsify a potential invariant, trueinvs is the (small) number of true invariants at a program point, testsuite is the size of the test suite, and procedures is the number of instrumented program points. The first two products multiply a number of invariants by the time to test each invariant.
If there are many true invariants over an input, then Daikon continues to check them all over the entire input. By contrast, if not many invariants are true, then Daikon need no longer check them once they are falsified (which in practice happens quickly). Daikon processes each procedure independently.
Another important factor affecting Daikon’s runtime is the number of
variables. Because invariants involve up to three variables each, the
number of invariants to check is cubic in the number of variables at a
single program point. Derived variables (such as a[i]
,
introduced whenever there is both an array a
and an integer
i
) can increase the number of variables substantially.
The ‘daikon.derive.Derivation.disable_derived_variables’ and individual
‘daikon.derive.*.*.enabled’ configuration variables
(see section Options to enable/disable derived variables) may be used
to disable derived variables altogether or selectively, at the cost of
detecting fewer invariants, especially over sequences.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Suppose that you run Daikon twice. The first time, you supply Daikon with traces T. The second time you supply Daikon with traces T+T’: either more files, or file(s) that are supersets of the original one(s). The second Daikon execution may report fewer invariants, more invariants, or a mix.
The second execution may report fewer invariants, because the additional data has eliminated overfitting (false positives). There may have been some accidental property of the shorter executions that is not true in the longer ones.
Even though fewer invariants are true on the second execution, Daikon may report invariants that it did not report on the first execution. The invariants were true on the first execution, but were not reported by Daikon. True invariants are not reported due to output filters describes why this might happen.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Running instrumented code can create very large ‘.dtrace’ files. This can be a problem because writing the large files can slow the target programs substantially, or because the large files may fill up your disk.
This section describes ways to work around this problem.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can reduce file size by specifying a trace file name that includes ‘.gz’ at the end. See the ‘--dtrace-file=FILENAME’ argument to Chicory or Kvasir, or the ‘DTRACEFILE’ environment variable. (Compression is the default if you don’t specify a filename.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Sometimes, the problem is just filling up your user account with large files. You can instead create dtrace files in a temporary directory. Under Unix, this is often called ‘/scratch’. Typically you should create a subdirectory called ‘/scratch/$USER/’.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The term “online execution” refers to running Daikon at the same time as the target program. The front end supplies information to Daikon directly over a socket or pipe, without writing any information to a file. This can avoid some I/O overhead, and it prevents filling up your disk with files.
The Chicory front end supports online execution via use of the ‘--daikon-online’ option (see section Chicory miscellaneous options). The Kvasir front end supports online execution via use of (normal or named) Unix pipes (see section Online execution).
In the future, Daikon may be able to output partial results as the target program is executing.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
It is usually possible to create an ‘.inv’ file equivalent to the one that Daikon would have computed, had Daikon been able to process your entire program over its full test suite. First, use the techniques below (see section Reducing program points (functions)) to split your ‘.dtrace’ file into parts. Next, run Daikon on each resulting ‘.dtrace’ file. Finally, use the MergeInvariants tool to combine the resulting ‘.inv’ files into one.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can record less information from each program execution, or you can make Daikon read less information from the trace files. It’s usually most efficient to do the pruning as early in the process as possible. For example, it is better to have the front end output less information, rather than have Daikon ignore some of the information.
9.2.5.1 Reducing program points (functions) | ||
9.2.5.2 Reducing variables | ||
9.2.5.3 Reducing executions |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are ways to compute invariants over a subset of the program points (functions) in your program.
trace-purge-fns.pl
script takes as
arguments a (Perl) regular expression and a list of files. It
modifies each file in place, removing every program point (function)
whose name matches the regular expression. The ‘-v’ flag means
to retain rather than discard matching program points. For instance,
to create two subparts of a ‘.dtrace’ file — one containing the
getters and setters, and the other containing all other functions —
use the following commands:
cp myprog.dtrace myprog-setters.dtrace trace-purge-fns.pl -v 'set|get' myprog-setters.dtrace cp myprog.dtrace myprog-non-setters.dtrace trace-purge-fns.pl 'set|get' myprog-non-setters.dtrace |
Also, the configuration variable ‘daikon.Daikon.ppt_perc’ allows a percentage of the program points to be processed. See section General configuration options, for details.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are ways to compute invariants over a subset of the variables in your program. This changes the resulting invariants, because invariants over the missing variables (including any relationship between a missing variable and a retained variable) are not detected or reported. For instance, you might remove uninteresting variables (or ones that shouldn’t be compared to certain others) or variables that use a lot of memory (such as some arrays).
trace-purge-vars.pl
script. Analogously to the
trace-purge-fns.pl
script, it removes certain variables from
all program points in a function (or retains them, with the
‘-v’ flag). After running this command, you will need
to edit the corresponding ‘.decls’ file by hand to remove the
same variables.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are ways to run Daikon over fewer executions of each program point. (You cannot combine the resulting invariants in order to obtain the same result as running Daikon over all the executions.)
daikon/scripts/trace-untruncate
program to remove the last,
possibly partial, record from the file:
trace-untruncate myfile.dtrace |
modifies ‘myfile.dtrace’ in place to remove the last record.
Alternately, you can use the
daikon/scripts/trace-untruncate-fast
program. It operates much
faster on very large files. In order to use
trace-untruncate-fast
, you must have already compiled it
(see section Installing Daikon).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Annotate (see section Annotate) and runtimechecker (see section Runtime-check instrumenter (runtimechecker)) tools use an external library (JTB,
http://compilers.cs.ucla.edu/jtb/) for parsing Java code. That
external library has an error in parsing logical shift operators such as
x << y
or x >> y
. Therefore, such invariants (along with
a few other invariants that cannot be properly formatted as Java code)
are suppressed from the output of these tools. (Annotate inserts them
as comments, and runtimechecker silently ignores them.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Before reporting or investigating a problem with Chicory, always check that the program executes properly when not being run under Chicory’s control.
For example, if a command such as
java daikon.Chicory DataStructures.StackArTester |
fails with an error, then first try
java DataStructures.StackArTester |
which is likely to fail with the same error.
If the latter command also fails, the problem is not with Chicory. First solve your Java problem, then once again attempt to use Chicory.
If the latter command does not fail, then you have found a bug in Chicory; please report it if it is not already explained in this manual.
9.4.1 VerifyError constant pool index error |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If Chicory throws an error such as the following:
Exception in thread "main" java.lang.VerifyError: (class: ps1/PublicTest, method: <init> signature: (Ljava/lang/String;)V) Illegal constant pool index |
then the problem is most likely that your classpath contains a version of the BCEL library that is not compatible with Java 5. The incompatible version might appear in ‘bcel.jar’, in Java’s ‘rt.jar’, or elsewhere. You should either remove that version of BCEL from your classpath, or you should ensure that it appears after ‘daikon.jar’, which contains its own version of BCEL. (If you are running Daikon from sources rather than from ‘daikon.jar’, then ensure that ‘$DAIKONDIR/java/lib/bcel.jar’ is the first version of BCEL on your classpath.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have any questions, can suggest ways to improve the documentation, find bugs in the system, or have suggestions for its improvement, please send email to daikon-developers@googlegroups.com. (If you can’t figure out how to do something or do not understand why Daikon works the way it does, that is a bug, too — in the Daikon documentation. Please report those as well.) We will try to assist you and to correct any problems, so please don’t hesitate to ask for help or report difficulties. Additionally, if you can contribute enhancements or bug fixes, those will be gratefully accepted.
In order for us to assist you, please provide a complete and useful bug report. Your bug report must provide all the information that is required in order to replicate the bug and verify that our fix corrects the problem. If you do not provide complete information, we will not be able to assist you.
Your bug report should include:
When users provide an inadequate bug report, it is frequently more difficult for us to reproduce an error than to correct it. If you make it easy for us to reproduce and verify the problem, then it is much more likely to be corrected. Thanks for helping us to help you!
You may also wish to take advantage of the Daikon mailing lists (see section Mailing lists).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
>>
, <<
, and >>>
), the
annotated/instrumented java may contain extra brackets in these
operators. For example, the expression x << y
in the input source
file may erroneously be translated as x <<<<<< y
in the
annotated/instrumented file.
This error’s presence will be immediately apparent if you try to compile the annotated/instrumented file and it fails to compile because the extra brackets make it syntactically illegal. In this case, the best solution we can recommend is that you manually fix the occurrence of the logical shift operator.
This error is caused by a bug in the parser generator that generates Daikon’s Java parser. We expect it will be fixed by the next release.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
More information on Daikon can be found in the Daikon Developer Manual (see (./developer)Top section ‘Introduction’ in Daikon Developer Manual). For instance, the Daikon Developer Manual indicates how to extend Daikon with new invariants, new derived variables, and front ends for new languages. It also contains information about the implementation and about how to debug.
You may find discussions on the mailing lists (see section Mailing lists) helpful. The mailing list archives may contain helpful information, but we strive to incorporate that information in this manual so that you don’t have to search the archives as well.
For further reading, see the list of publications at the Daikon homepage, http://plse.cs.washington.edu/daikon/pubs/.