Jetris hangs after NegativeArraySizeException during long-running fuzzing (48h experiment)

[fyt1008]

Description

When running a long-running (48h) comparative experiment with Jetris, the process becomes stuck after printing a NegativeArraySizeException.

The program does not exit, does not report further progress, and no new test cases are generated afterward.

This blocks the experiment and leaves later intervals empty.

---

Environment

• Experiment type: 48h comparative fuzzing experiment

---

Observed behavior

After the following output, the process hangs indefinitely:

java.lang.NegativeArraySizeException
    at org.objectweb.asm.Frame.merge(Frame.java:1222)
    at org.objectweb.asm.MethodWriter.computeAllFrames(MethodWriter.java:1607)
    at org.objectweb.asm.MethodWriter.visitMaxs(MethodWriter.java:1543)
    at soot.AbstractASMBackend.generateMethods(AbstractASMBackend.java:405)
    at soot.AbstractASMBackend.generateByteCode(AbstractASMBackend.java:313)
    at soot.AbstractASMBackend.generateClassFile(AbstractASMBackend.java:263)
    at utils.ClassUtils.saveClass(ClassUtils.java:148)
    at Main.fuzzing(Main.java:181)
    at Main.main(Main.java:44)

After this, Jetris prints GenerationFailed once and then stops making progress:

• No new log output
• No new test cases generated
• The process does not terminate

---

Expected behavior

One of the following would be expected instead:

• The fuzzer terminates after an unrecoverable generation failure
• Or the exception is handled and fuzzing continues
• Or the failure is reported clearly and the experiment exits gracefully

---

Additional information

• During the comparative experiment, I recorded the executed test cases every 10 minutes.
• All intervals after this failure are empty, indicating that fuzzing stopped completely.
• This suggests the main fuzzing loop may be stuck after a generation failure.
• If helpful, I can provide the full log.

[fyt1008]

Update: Root cause analysis & workaround

After further investigation, the hang is not caused by NegativeArraySizeException itself, but by the fact that CFG / code generation can enter a non-terminating state after a failed generation.

Specifically:

• Main.fuzzing() runs inside an infinite while (true) loop
• After a generation failure (e.g., ASM / Soot throws NegativeArraySizeException), the exception is caught
• However, the current fuzzing iteration is not aborted
• Control flow may remain stuck inside CFG/code generation
• As a result:
  • No new test cases are generated
  • No new logs are printed
  • The process stays alive but makes no progress

This explains why all later experiment intervals remain empty in long-running (e.g., 48h) experiments.

---

Workaround: add a CFG generation budget

A practical workaround is to add a step (operation) budget to the CFG / code generation logic.

The idea is to limit how many CFG generation steps are allowed per fuzzing iteration.
Once the budget is exhausted, the current generation is aborted and fuzzing continues with the next iteration.

Example (simplified):

// Generator.java
private static int STEP_COUNTER = 0;
private static final int MAX_STEP =
    Math.max(2000, FuzzingConfig.MAX_FUZZ_STEP * 200);

public static void resetStepCounter() {
    STEP_COUNTER = 0;
}

public static boolean consumeStep() {
    STEP_COUNTER++;
    return STEP_COUNTER <= MAX_STEP;
}

Guard CFG / block generation:

Add a guard to every CFG / basic block generation entry point so that generation is aborted once the step budget is exhausted.

public static BasicBlock nextBlock(...) {
    if (!consumeStep()) {
        return null; // abort this generation
    }
    ...
}

Reset the counter per fuzzing iteration:

// Main.fuzzing()
Generator.resetStepCounter();
guidedCodeGeneration(clazz, method);

---

Result

With this change:

• A single stuck CFG generation can no longer block the entire fuzzing process

• Failed generations are skipped safely

• Long-running experiments continue producing test cases normally

This avoids killing the whole JVM process and makes fuzzing more robust against rare but unrecoverable generation failures.