Questions Regarding "Frequent Modifications Mining"

[goodtaeeun]

Hello, Jiang!
My name is Tae Eun Kim.
I am a Computer Science undergraduate student in Handong Univ., Korea.

I am currently interested in APR and recently read your paper, the one about SimFix.
I am also interested in using patches of similar codes, since it can reduce the search space, complementing the limitation of search-based APR. So it is not a surprise that SimFix caught my attention. It was a mind blowing approach on effective exploitation of search space.

After reading your paper, I wanted to see how it works, so I was going through the implementation you opened on Github.
However, I came across a question.

I couldn't find the mining stage of "frequent modifications" on-line, neither the implementation of intersection of S1 and S2, as you mentioned in the paper.

So I was wondering if you can point out where this stage takes place.

Could you help me find answers to my questions?

With all the respect,
Kim.

[xgdsmileboy]

Hi Kim,

Thanks for your interest in SimFix and sorry for my late reply (I have replied your email, but it was bounced by your email system).

First of all, I couldn't find the mining stage of "frequent modifications" on-line, neither the implementation of intersection of S1 and S2, as you mentioned in the paper.

This repository is exactly the implementation corresponding to the paper. For efficiency, the current implementation implicitly achieves the intersection process by filtering out invalid modifications when extracting modifications according to those "frequent modifications” shown in the paper.

Second, in your paper, you said you excluded "Deletion" modification, but it was present in the implementation.

Exactly, SimFix will extract “Deletion” modifications, but it would not apply them to the candidate buggy code.

Hope it can help.

[goodtaeeun]

Thanks for your kind explanation!!

Then I will examine the Matching process, where the modification extraction takes place.
I admire your paper and this implementation!

Thanks again,
Kim

P.S.

I recently read a paper "Practical Program Repair via Bytecode Mutation", by Ghanbari et al.
In this paper, Ghanbari says that "as also confirmed by SimFix authors, SimFix was unable to locate reusable code snippets in the new dataset". New dataset here refers to 192 bugs in the Defects4J v 1.4.0.

I wonder what would be the reason for SimFix to not be able to locate reusable code snippets. I think SimFix's approach seems to have no problem. Do you have any suggestions? Maybe it could be because of different experiment settings?

[xiongyingfei]

I recently read a paper "Practical Program Repair via Bytecode Mutation", by Ghanbari et al.
In this paper, Ghanbari says that "as also confirmed by SimFix authors, SimFix was unable to locate reusable code snippets in the new dataset". New dataset here refers to 192 bugs in the Defects4J v 1.4.0.
I wonder what would be the reason for SimFix to not be able to locate reusable code snippets. I think SimFix's approach seems to have no problem. Do you have any suggestions? Maybe it could be because of different experiment settings?

Hi Kim,

I am Yingfei Xiong, an author of the SimFix paper.

To clarify, we never confirmed that SimFix cannot fix any new bugs on Defects4J v2.0 (the previous v1.4). In fact, we know at least two new bugs in Defects4J v2.0 can be fixed by SimFix. What we were asked is "Can SimFix generate a patch when no reusable code snippet is available?" The answer is, of course, "no".

However, SimFix does perform much worse on the new bugs introduced in v2.0 than v1.2. This is because the size of the new projects in Defects4J 2.0 is much smaller than the previous projects. To use SimFix, we may find projects of similar type and add their source code for searching for reusable snippets.

Best Regards,
Yingfei