Fix the bug exposed by Time_7 fault localization

[DehengYang]

the original code in GZoltarFaultLoclaization.java :
new GZoltar(System.getProperty("user.dir"))

will lead to unexpected failed test cases when localizing Time buggy projects, (e.g., this leads to the failure of org.joda.time.TestSerialization#testSerializedMutableDateTime when localizing Time_7.

The failing trace is :

java.io.FileNotFoundException: src/test/resources/MutableDateTime.dat (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:146)
at java.io.FileInputStream.(FileInputStream.java:101)
at org.joda.time.TestSerialization.loadAndCompare(TestSerialization.java:293)
at org.joda.time.TestSerialization.testSerializedMutableDateTime(TestSerialization.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
at com.gzoltar.core.instr.testing.junit.JUnitRunner.run(JUnitRunner.java:47)
at com.gzoltar.core.instr.Runner.main(Runner.java:46)

Based on this, we can know that these unexpected failed tests are caused by incorrect working directory when initializing GZoltar fault localizer.

Therefore, the GZoltar working dir should be the bugDir, rather than the current FL project dir.

[Kui-Liu]

Did you try this parameter setting for each Defects4J bug?
I remembered that I tried this parameter, it can throw some unexpected exceptions for some Defects4J bugs.

[DehengYang]

No, I have only studied the failure exposed by Time_7. In Time_7, it does not throw any exceptions, instead, the failure (i.e., the unexpected failed tests) needs to be examined manually (using Debugging or print statements).

And we can ensure that if GZoltar is not initialized with the buggy program directory, there will be also some Defectes4J bugs that may obtain many extra failed tests which use relative paths to test projects, just like org.joda.time.TestSerialization#testSerializedMutableDateTime in Time_7.

As you mentioned, if GZoltar is initialized with the buggy program directory, there will be some unexpected exceptions.

So... I think GZoltar 0.1.1 may have several bugs in itself, which has already negatively affected the accuracy of current fault localization. It is really necessary and highly demanded to implement GZoltar with java. （This can be an idea as well as a meaningful contribution for the APR and FL community).

Finally, maybe this pull request still needs/deserves more explorations/efforts.

Thank you again for your reply.