Dynamic Repairing

To investigate the effectiveness of DecLLM's dynamic repairing, we manually reviewed 50 cases where DecLLM successfully fixed a runtime error, and we categorized these fixes into three categories. The two major categories are output formatting errors and minor algorithmic errors, which accounted for 48% and 42% of the sampled cases, respectively. Output formatting errors typically involve issues related to the structure or formatting of the output, like missing a newline after each output. As for minor algorithmic errors, they typically include small mistakes such as a reversed plus/minus sign or reversed program logic. The remaining 10% belongs to memory corruption issues that stem from inference errors in the decompiler outputs. We further generalize into two patterns, and illustrate the repairing process as follows: 

Pattern 1 Inference error induce from template error:

Three out of the five cases belong to this pattern, and we present a sample as follows. In the source code (Fig. a), the variable arr is declared as a 2D array. However, due to a decompilation template error(Fig. b), the decompiler incorrectly inferred it as an integer pointer (v13) and created a call to alloca to represent the array declaration. Initially, did not handle the issue. However, it triggers an out-of-bound access on line 10 (line 8 of Fig. c ). After supplying the ASAN error and the error location, we noted that the LLM had assigned the result from alloca  to v13 (line 4 of Fig. d ), effectively fixing the memory corruption problem.