SimFix crashed in some bugs

[claudeyj]

Hi Prof. Jiang, I'm using SimFix to fix some new bugs and it's really so powerful and easy to use. But I found some potential issues with SimFix and hope to confirm with you. The workflow of SimFix is G & V, i.e., generation and validation. In the validation stage, for each patch, SimFix will execute the failing tests first. If there's some failing tests, then it will skip to the next patch. Otherwise it will continue to execute the whole test suite. Here https://github.com/xgdsmileboy/SimFix/blob/c2a531961ab871a4866d0bc1962d7f021810f59d/src/cofix/main/Repair.java#L456 splits the failing test information into testClass and testMethod, which is reasonable in most cases, because that's the format of the failing tests provided by defects4j in most cases. However, in some cases that may not hold. For example, the program for logging failing tests information: https://github.com/rjust/defects4j/blob/29d84487b1d3828a4ba7bdd0ed8110099c821883/framework/lib/formatter/src/edu/washington/cs/mut/testrunner/Formatter.java#L100 will output testClass::testMethod in most cases, but when the bug leads to the JUnit Initialization Failure(which happens in some Time projects), it will only output testClass. In this case L456 in Repair.java will trigger a crash due to index error (list out of range). If you can confirm this then I'd be happy to create a pull request to fix this issue so that SimFix won't fail on similar cases. Thanks a lot for taking a look!

[xgdsmileboy]

@claudeyj Thanks for your detailed information. Actually, I did not incur the same issue on Time projects. I would appreciate for your contribution to fix it. Besides, if you can also provide a test case regarding this bug, it would be best.

Thanks.

[claudeyj]

Thanks a lot! I will create a pull request soon.