3 minutes ago

Joda-Time is a standard date and time library for Java.


Issue 77: https://github.com/JodaOrg/joda-time/issues/77

after calling addDays(0), value of MutableDateTime while it shouldn't

Test case:

final MutableDateTime mdt = new MutableDateTime(2011, 10, 30, 3, 0, 0, 0, DateTimeZone.forID("Europe/Berlin"));
System.out.println("Start date:   " + mdt + " (" + mdt.toInstant().getMillis() + ")");
System.out.println("addHours(-1): " + mdt + " (" + mdt.toInstant().getMillis() + ")");
System.out.println("addHours(0):  " + mdt + " (" + mdt.toInstant().getMillis() + ")");
System.out.println("addDays(0):   " + mdt + " (" + mdt.toInstant().getMillis() + ")");

Start date:   2011-10-30T03:00:00.000+01:00 (1319940000000)   
addHours(-1): 2011-10-30T02:00:00.000+01:00 (1319936400000)  
addHours(0):  2011-10-30T02:00:00.000+01:00 (1319936400000)    
addDays(0):   2011-10-30T02:00:00.000+01:00 (1319932800000)   
Start date:   2011-10-30T03:00:00.000+01:00 (1319940000000)    OK
addHours(-1): 2011-10-30T02:00:00.000+01:00 (1319936400000)    OK
addHours(0):  2011-10-30T02:00:00.000+01:00 (1319936400000)    OK, no change in time
addDays(0):   2011-10-30T02:00:00.000+02:00 (1319932800000)    error, time has changed by 1 hour

Analyzed Result

106 seconds ago

Result from Ziyuan:

The best predicate:

hours >= -0.0 (org.joda.time.MutableDateTime:804)


20 seconds ago

Ziyuan's analysis result is interesting for this one. The original bug report believed that the bug happens when method AddDays is invoked with parameter 0. The fix is as follows.

That is, the authors simply added a check so that when the parameter is 0, nothing is done. The fix obviously made the test case pass. However, what Ziyuan's output means is that the bug is actually not due to the parameter 0. Rather it is due to this parameter -1 used when invoking method AddHours. Our investigation shows that indeed, the bug goes away if we change -1 to 1 without using the bug fix. This shows that in fact the bug is not "fixed" and the bug has been explained wrongly. Subsequently, we made a bug report based on the finding at https://github.com/JodaOrg/joda-time/issues/310. The author of project then confirmed that in fact, that particular time is around a daylight savings change and therefore the result of the test case is in fact correct!


We feed the passed test cases from Ziyuan to Daikon. After a while, Daikon throws an exception as below:

[1:49:06 PM]: Reading ./DaikonTestIssue77.dtrace.gz (line 1775835, 31.23%) ... Exception in thread "main" java.lang.Error: java.lang.OutOfMemoryError: GC overhead limit exceeded

[1:49:08 PM]: Reading ./DaikonTes taIts sdauiek7o7n..FidleIO.read_dtartacae_.tgzr ace(_lfiinlee s1(7F7i58l3e5, 31.23%) I..O.. 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$BnM.optimize(Pattern.java:5408)

at java.util.regex.Pattern.compile(Pattern.java:1709)

at java.util.regex.Pattern.(Pattern.java:1351)

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.VarInfoName.parse(VarInfoName.java:110)

at daikon.VarInfoName.parse(VarInfoName.java:122)

at daikon.VarInfo.(VarInfo.java:609)

at daikon.VarInfo.(VarInfo.java:633)

at daikon.VarInfo.arrayclone_simple(VarInfo.java:732)

at daikon.PptConditional.ctor_vis_helper(PptConditional.java:67)

at daikon.PptConditional.(PptConditional.java:39)

at daikon.split.PptSplitter.(PptSplitter.java:100)

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:49:09 PM]: Reading ./DaikonTestIssue77.dtrace.gz (line 1775835, 31.23%) ...


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.


var0 = prim : int:2011 :

var1 = prim : int:10 :

var2 = prim : int:30 :

var3 = prim : int:3 :

var4 = prim : int:0 :

var5 = prim : int:0 :

var6 = prim : int:0 :

var7 = prim : java.lang.String:"Europe/Berlin" :

var8 = method : org.joda.time.DateTimeZone.forID(java.lang.String) : var7

var9 = cons : org.joda.time.MutableDateTime.<init>(int,int,int,int,int,int,int,org.joda.time.DateTimeZone) : var0 var1 var2 var3 var4 var5 var6 var8

var10 = prim : int:-1 :

var11 = method : org.joda.time.MutableDateTime.addHours(int) : var9 var10

var12 = prim : int:0 :

var13 = method : org.joda.time.MutableDateTime.addDays(int) : var9 var12