codespecs / daikon-dot-net-front-end Goto Github PK

It's possible there may be a store and then a branch within the function.

Want to make sure don't include a synthesized return in this case.

Line 37 in VariableVisitor.cs.

I'm leaning toward keeping it at this point.

Allow users to specify pure functions in a file -- this as a command line 
argument.

Add instrumentation to execute these calls.

Make a simple hello world program with method calls with a few different types, 
figure out what the difference between the Chicory and DNFE uses of each are.

Set the verbose mode to false by default.

The exception sorting code executes multiple passes over the method's 
operations. This could potentially be expensive for really long methods. I 
suspect however it will not be an issue, and would just make the code more 
confusing for speed increase. Potentially worth a look however.

They seem to be doing the same thing but can't easily be combined without 
examining side effects.

Add this as a command line option.

Print the number not the val.

Exits with a NullRef exception

Instrument multiple return locations, with the program point hierarchy 
established have the single program point as parents.

Note that debug builds collapse return statements to the end of the function 
for debugging. Ignoring this for now.

Instead of doing Math.Pow everytime store this in the occurenceCount map, this 
should probably map function name to pair where the first element is the 
occurencesCount as currently and the second element is the "every" value that 
is currently calculated in each pass. This would be updated wheenver 
oldOcurrences % frontEndArgs.SampleStart == 0.

This would require ample testing of ocurrenceCount, which doesn't currently 
exist.

This will need some tuning of tests.

Right now for STDOUT printing we write to a temp file and then read that tem 
file. This is because of the way our writer is set up. I don't know if you can 
grab a console for the writer.

The daikon standard allows for special printing of objects containing a 
variable of their own type.

They cause a NPE crash.

In Reflector.cs line 25 there's a TODO for implement program point recognition, 
but it's surrounded by dead code. Figure out what's going on here and handles 
as necessary.

Right now I'm not sure how to convert the CCI type to assembly qualified-name, 
in ConverCCITypeToString() function.

There's some debug code left in DeclarationPrinter.cs.

All marked with TODOs

From the daikon developer manual:
Second, between two classes that are related by inheritance, corresponding 
program points relate — for example, java.util.Vector:::CLASS is a child of 
java.util.List:::CLASS.

Make sure we can safely and quickly do this, or come up with another fool-proof 
way to get the element type.

When we've determined how to implement multiple return locations, clean up the 
instrument return signature. Right now shouldHandleExceptions is always true at 
the only call site.

Right now the program fails if there's multithreading -- change this so it's 
allowed.

Acquire a lock on the writer before we start inspecting any method, release the 
lock when we're done.

There are some weird cases where we can't load a field type for an object. This 
we weird because we use the same mechanism to determine which field types to 
load that we actually load the fields from. The GetFieldValue() method is a 
workaround for this but it can fail. For now we just return null, maybe make 
this nonsensical before a full fix is available.

The CCI code prints an error and continues. Todd say everything seemed fine.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Run the front end on any valid .exe file with --linked-lists option enabled. 
Doing so throws an exception:

Unhandled Exception: System.ArgumentNullException: Value cannot be null.
Parameter name: value

The sample start allows for limited printing of output.

Sample program:

    class Program
    {
        static void Main(string[] args)
        {
            var x = new LinkedList<LinkedList<Int32>>[10];
            Test(x);
        }

        static void Test(LinkedList<LinkedList<Int32>>[] advancedType)
        {

        }
    }

Successfully runs through the front end, but has a conversion error.

$ ./DotNetFrontEndLauncher AdvancedTypeTest.exe
Processing executable AdvancedTypeTest...
Argument processing complete
Couldn't convert type with assembly qualified name: 
System.Collections.Generic.LinkedList<System.Collections.Generic.LinkedList<Syst
em.Int32>>[], AdvancedTypeTest, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=null
Rewriting complete
Loading complete. Starting program.
Program complete. Exiting DNFE.

When running the resulting dtrace through Daikon, an exception is thrown:

$ daikon AdvancedTypeTest.dtrace
Daikon version 4.6.4, released June 23, 2010; http://pag.csail.mit.edu/daikon.
Processing trace data; reading 1 dtrace file:
Exception in thread "main" java.lang.Error: daikon.Daikon$TerminationMessage: 
Error at line 277 in file AdvancedTypeTest.dtrace: no ppt_tag_separator in 
'nonsensical'
        at daikon.FileIO.read_data_trace_files(FileIO.java:1016)
        at daikon.FileIO.read_data_trace_files(FileIO.java:980)
        at daikon.Daikon.process_data(Daikon.java:1823)
        at daikon.Daikon.mainHelper(Daikon.java:575)
        at daikon.Daikon.main(Daikon.java:454)
Caused by: daikon.Daikon$TerminationMessage: Error at line 277 in file 
AdvancedTypeTest.dtrace: no ppt_tag_separator in 'nonsensical'
        at daikon.FileIO.read_data_trace_record(FileIO.java:1674)
        at daikon.FileIO.read_data_trace_file(FileIO.java:1479)
        at daikon.FileIO.read_data_trace_files(FileIO.java:999)
        ... 4 more

Line 266

In DeclarationPrinter parent type should be added for static fields.

Talk with Mike about how to do this.

Implement comparability, right now we just print that all things are comparable.

This would probably involve adding a new map in ReflectionArgs.

A zero-feature approach would involve mapping at least each type to a unique 
integer.

A real approach would look at each type, use reflection to see if it implements 
IComparable, then check the generic to see what it's comparable to and match up 
the numbers in the table.

We don't know what to interpret Exception object as, so we just downcast them 
to Object for now.

namespace HelloWorld
{
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;

  public class AdvancedCollections
  {
    public static void Main(String[] args)
    {
      ArrayHolder holder = new ArrayHolder();

      List<int> intSet = new List<int>();
      intSet.Add(-1);
      intSet.Add(0);
      intSet.Add(1);
      holder.updateArray(intSet.ToArray());

      List<int> intSet2 = new List<int>();
      intSet2.Add(10);
      intSet2.Add(11);
      holder.updateArray(intSet2.ToArray());
    }
  }

  public class ArrayHolder
  {
    HashSet<int> baseArray;
    // TODO: Figure out what goes wrong with expanded array
    HashSet<int> expandedArray;

    public ArrayHolder()
    {
      this.baseArray = new HashSet<int>();
      this.expandedArray = new HashSet<int>();
    }

    public void updateArray(int[] integers)
    {
      this.baseArray.Clear();
      this.expandedArray.Clear();
      this.expandedArray.Add(integers[0] + 4);
      for (int i = 0; i < integers.Length; i++)
      {
        baseArray.Add(integers[i] + 5);
        expandedArray.Add(integers[i] + 5);
      }
      this.expandedArray.Add(integers[integers.Length - 1] + 6);
    }
  }
}

Make sure that the program works as expected with programs running built for 
older versions of mscorlib, and older versions of .NET

What should the VarKind of e.g. String.Empty be?

Maybe it should be a field, but then it'd need an enclosing-var. What should 
that enclosing var then be?

Right now it doesn't have a special kind.

Reflector.cs: 221

I imagine this could be when the --run_program arg is passed. Should be 
testable when we get test coverage data.

ReflectionArgs.cs 157

In RefelctionArgs.cs

Try getting the type name from the obj's get type so we don't have to build it 
up manually.

I think the compiler will automatically add a type. If such a situation existed 
then our method of instrumenting return values would need to be modified.

Using assembly qualified name is annoying because we have to build and then 
parse it. Instead make an object to specially handle this.

Uncomment exception handling code

These are described in the daikon developer manual

We need to a lock on the writer while we are writing.

Talk with Mike re: priority on this

Gives an exception when we try to pull out a local variable

In DeclarationPrinter, the PrintParentObjectFields method, figure out what to 
do if type can't be resolved

Would be nice to see what's being tested and what still needs it.

Write a "check-in" script that builds and runs the tests.

Figure out the URL for the command line args and add it in RefelctionArgs.cs