Data in gsflib could get slightly erased wrongly sometimes

[loveemu]

Summary

Gsfopt is possible to write wrong value to ROM coverage in gsflib optimization (mode -l for instance). The condition to cause the glitch might not be very common, but it might wipe the ROM data (especially a sample) quite slightly without being noticed.

How to fix : If you worry about gsflibs that you have optimized by old gsfopt, redo the gsflib optimization with unoptimized ROM, then replace your gsflib to new one.

Here I can provide a special build of gsfopt 1.2.8, which can indicate the possible ROM offset which gets erased wrongly. gsfopt-1.2.8-win32-overflow-indicator.zip

Occurrence condition

The mechanism of the glitch is simple. It's too stupid.

u8 * rom_coverage;
u8 * another_rom_coverage;

for (u32 offset = 0; offset < size; offset++) {
    if (rom_coverage[offset] + another_rom_coverage[offset] <= 0xff) {
        rom_coverage[offset] += another_rom_coverage[offset];
    } else {
        rom_coverage[offset] += 0xff; // wait, why += is placed here
    }
}

In words: the glitch occurs when the song A refers to a certain address once, and another song B refers to the same address at least 255 times.

Screenshot

I have found the glitch since gsfopt destroyed a certain instrument of Juka and the Monophonic Menace BGM 7.