Joda-Time is a standard date and time library for Java. Result from Ziyuan: We feed the passed test cases from Ziyuan to Daikon. After a while, Daikon throws an exception as below: [1:37:51 PM]: Reading ./DaikonTestIssue21.dtrace.gz (line 1792649, 67.19%) ... E[1:37:53 PM]: Reading ./DaikonTestIssue21j.advtar.laacneg..gz E(rlrionre: 1j7a9va2.6l4a9n,g .6O7u.tOfM1e9m%o)ry E.r.r.o r: GC overhead limit exceeded at daikon.FileIO.read_data_trace_files(FileIO.java:1006) at daikon.FileIO.read_data_trace_files(FileIO.java:965) at daikon.Daikon.process_data(Daikon.java:1859) at daikon.Daikon.mainHelper(Daikon.java:573) at daikon.Daikon.main(Daikon.java:453) Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.regex.Pattern.compile(Pattern.java:1686) at java.util.regex.Pattern. at java.util.regex.Pattern.compile(Pattern.java:1054) at java.lang.String.replace(String.java:2239) at daikon.VarInfoName.parse(VarInfoName.java:78) at daikon.VarInfoName.parse(VarInfoName.java:110) at daikon.VarInfoName.parse(VarInfoName.java:110) at daikon.VarInfoName.parse(VarInfoName.java:110) at daikon.VarInfo. at daikon.VarInfo. at daikon.VarInfo.arrayclone_simple(VarInfo.java:732) at daikon.PptConditional.ctor_vis_helper(PptConditional.java:67) at daikon.PptConditional. at daikon.split.PptSplitter. at daikon.PptTopLevel.addConditions(PptTopLevel.java:2664) at daikon.Daikon.setup_splitters(Daikon.java:1705) at daikon.Daikon.init_ppt(Daikon.java:1387) at daikon.FileIO.read_data_trace_record(FileIO.java:1637) at daikon.FileIO.read_data_trace_file(FileIO.java:1489) at daikon.FileIO.read_data_trace_files(FileIO.java:987) ... 4 more [1:37:55 PM]: Reading ./DaikonTestIssue21.dtrace.gz (line 1792649, 67.19%) ... The input of FailureDoc is a sequence. In this case, we manually create below sequence as its input. However, FailureDoc says that the sequence has not error and does not give any explanation. START SEQUENCE var0 = prim : java.lang.String:"en" : var1 = prim : java.lang.String:"GB" : var2 = method : java.util.Locale.createConstant(java.lang.String, java.lang.String) : var0 var1 var3 = prim : java.lang.String:"M d" : var4 = method : org.joda.time.format.DateTimeFormat.forPattern(java.lang.String) : var3 var5 = method : org.joda.time.format.DateTimeFormatter.withLocale(java.util.Locale) : var4 var2 var6 = prim : int:2000 : var7 = prim : int:1 : var8 = prim : int:1 : var9 = prim : int:0 : var10 = prim : int:0 : var11 = prim : int:0 : var12 = prim : int:0 : var13 = prim : java.lang.String:"America/New_York" : var14 = method : org.joda.time.DateTimeZone.forID(java.lang.String) : var13 var15 = cons : org.joda.time.MutableDateTime.<init>(int,int,int,int,int,int,int,org.joda.time.DateTimeZone) : var6 var7 var8 var9 var10 var11 var12 var14 var16 = prim : java.lang.String:"2 29" : var17 = prim : int:0 : var18 = method : org.joda.time.format.DateTimeFormatter.parseInto(org.joda.time.ReadWritableInstant,java.lang.String,int) : var5 var15 var16 var17 END SEQUENCE
http://www.joda.org/joda-time/
Issue 21: https://github.com/JodaOrg/joda-time/issues/21
Problem:
The following code (which can be added to org.joda.time.format.TestDateTimeFormatter) breaks, because the input mutable date time's millis appear to be mishandled and the year for the parse is changed to 1999:
Testcase:
The following predicate is output since the first predicate is not the converged result of the selective sampling:
2.0*bucket.iDefaultYear >= 4007.0 (org.joda.time.format.DateTimeFormatter:714)
The bug is located in the invoked method at org.joda.time.format.DateTimeFormatter:712. The actual reason for this bug is that the year is parsed incorrectly in the method. In the test case, year 2000 is a leap year and therefore Feb 29 is a valid date. However, internally the year is parsed as 1999 which causes an invalid date checking to fail.
The predicate generated by Ziyuan is correct with respect to the test cases given. However, it is not the best predicate there is since the bug is related to whether a year is a leap year or not. Ziyuan failed to generate the best predicate because the feature on whether a year is a leap year or not is not part of the feature vectors. The underlying reason for that is while in the year class there is a method which returns whether a year is leap or not, it is (ill) designed such that it would take a year as parameter. Ziyuan currently does not support classification using features which can be obtained through inspector methods with parameters.
We remark that we manually change the implementation of the method (so that it doesn't take any parameter) and Ziyuan would learn the best predicate correctly inside that method.