[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9. Troubleshooting

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.1 Problems running Daikon

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] [ ? ]

9.1.1 Can’t run Daikon: NoClassDefFoundError

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] [ ? ]

9.1.2 Too much output

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] [ ? ]

9.1.3 Missing output invariants

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] [ ? ]

9.1.4 True invariants are not reported due to output filters

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:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.1.5 No samples and no output

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] [ ? ]

9.1.6 No return from procedure

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] [ ? ]

9.1.7 Unsupported class version

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] [ ? ]

9.1.8 Out of memory

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] [ ? ]

9.1.9 Simplify errors

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] [ ? ]

9.1.10 Contradictory invariants

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] [ ? ]

9.1.11 Method needs to be implemented

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] [ ? ]

9.1.12 Daikon runs slowly

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] [ ? ]

9.1.12.1 Slow creation of large trace files

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] [ ? ]

9.1.12.2 Slow inference of invariants

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] [ ? ]

9.1.13 Bigger traces cause invariants to appear

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] [ ? ]

9.2 Large data trace (.dtrace) files

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] [ ? ]

9.2.1 Compressed .dtrace files

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] [ ? ]

9.2.2 Save large files in a scratch directory

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] [ ? ]

9.2.3 Run Daikon online

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] [ ? ]

9.2.4 Create multiple smaller data trace files

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] [ ? ]

9.2.5 Record or read less information in the data trace file

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.2.5.1 Reducing program points (functions)

Here are ways to compute invariants over a subset of the program points (functions) in your program.

  1. Make your front end instrument fewer files. This is often mast applicable if you are using a source-based front end.
  2. You can instrument fewer procedures.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.2.5.2 Reducing variables

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

  1. You can reduce the number of variables that are output by instrumented code — for instance, output ‘a’ and ‘a.b’ but not ‘a.b.c’. Do this by reducing the class/structure instrumentation depth.
  2. With Kvasir, you can either ignore all global and/or static variables with the ‘--ignore-globals’ and ‘--ignore-static-vars’ options or manually specify a subset of variables to trace using the ‘--var-list-file’ option (see section Tracing only part of a program section for details)
  3. You can pare down an existing ‘.dtrace’ file using the 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.
  4. You can make Daikon ignore certain variables rather than modifying the ‘.dtrace’ file directly. Analogously with the ‘--ppt-select-pattern’ and ‘--ppt-omit-pattern’ flags, the ‘--var-select-pattern’ and ‘--var-omit-pattern’ flags restrict which variables Daikon processes (see Processing only part of the trace file, and Chicory options).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.2.5.3 Reducing executions

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

  1. If you have multiple ‘.dtrace’ files (perhaps resulting from multiple program runs), you can run Daikon on just some of them.
  2. You can terminate the instrumented program when it has created a sufficiently large ‘.dtrace’ file. If you interrupt the program while it is in the middle of writing a record to the ‘.dtrace’ file, the last record may be only partially written. Use the 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).

  3. You can cause the front end to record only a subset of executions of a given procedure, rather than every execution. For example, Chicory’s ‘--sample-start’ command-line option does this (see section Chicory miscellaneous options).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.3 Parsing Java 5.0 code

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] [ ? ]

9.4 Problems with Chicory

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.4.1 VerifyError constant pool index error

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] [ ? ]

9.5 Reporting problems

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] [ ? ]

9.6 Known bugs


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

9.7 Further reading

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