#25 Possible segfault due to fixed size of contention array

[Philip Kendall]

If an RZX file contains a frame which we play much
slower than the recording emulator, it may be possible
that the tstate count for that frame goes over 80000.
At this point, Fuse will likely segfault as the
ula.c:ula_contention array contains 'only' 80000 entries.

I can't instantly see any ways around this without
introducing a performance penalty, so opening this bug.

[Philip Kendall]

[Philip Kendall]

Logged In: YES
user_id=29214
Originator: YES

An equivalent problem is produced by filling all of memory with 0xdd (only possible on eg +2A/+3), at which point we never exit the main z80_do_opcodes() loop. Attached is a test case for this, with thanks to Woody. I'm not intending to fix this for 0.8.
File Added: DDPlus3.tap

[Philip Kendall]

RZX file containing a >100000 tstate frame

[Philip Kendall]

Logged In: YES
user_id=29214
Originator: YES

Despite my previous comment, these aren't really equivalent cases: in the RZX case, we are running off the end of the contention array because we keep going around the main Z80 loop without a frame event happening to reduce the tstate count. In the second case, we are never running round the main Z80 loop, which is a different problem.

I think the RZX case can be solved by having a "sentinel" event (at say 79000 tstates) which, if hit, simply reduces the tstate count and continues. The "all of memory is DD" case is a bit harder.

Attached is a (hand-crafted) RZX file which contains ~100000 tstates in a frame. This doesn't actually cause Fuse to crash on my machine, but that's slightly irrelevant.
File Added: verylongframe.rzx

[Philip Kendall]

Logged In: YES
user_id=29214
Originator: YES

Code committed to add the sentinel event: if tstates is ever >= 79000 when the main opcode loop is entered, it is reduced by 8000.