Teddybear's Revenge crashes when run from autoexec with specific vmem_delay and cycles values

[PoulpSquad]

Are you using the latest Dosbox-Staging Version?

• I have checked releases and am using the latest release.

Different version than latest?

No response

What Operating System are you using?

Windows 10

If Other OS, please describe

No response

Relevant hardware info

i7 7700K, 32GB RAM, GTX 1070

Have you checked that no other similar issue already exists?

• I have searched and not found similar issues.

A clear and concise description of what the bug is.

As discussed in #3723, demo "Teddybear's Revenge" crashes Staging when run from [autoexec] with vmem_delay and a high cycles value.

As a reminder, I'll paste a sample of what weirddan455 found investigating the issue discovered by interloper98:

"As for the crash on start @interloper98 found... that's a hell of an edge case you found 😉 . It's only reproducible for me if I also add the demo to my [autoexec]. One of the first things the demo does is call INT10_VideoState_Save. You've set the real mode cycles so high and also added a vmem delay so it's doing this before VGA_SetupDrawing had a chance to run for the first time. Basically, the demo started running before the welcome screen could even be shown 😉"

Grabbing popcorn, this stuff is geeky as hell and I love it!

Steps to reproduce the behaviour.

Explain how to reproduce

1. Set vmem_delay to on or any value >0
2. Set cycles= to a high enough value
3. Run demo from [autoexec] section

Download URL of affected game or software

No response

Your configuration

[dosbox]
vmem_delay= >0 or on

[autoexec]
mount c f:\dosbox -t dir
c:
cd teddy
teddy.exe

Provide a Log

No response

Code of Conduct & Contributing Guidelines

• Yes, I agree.

[interloper98]

Grabbing popcorn, this stuff is geeky as hell and I love it!

You and me, too, @PoulpSquad. 🍿

Also - That's some detective work for that cursor issue, @weirddan455! 🥳

This project just keep getting better.

[weirddan455]

Repro steps are use this config exactly. Bug doesn't trigger is cycles are too low or vmem_delay isn't in a narrow range. Setting it to off doesn't trigger it and setting it 10000 also doesn't trigger it but 8000 seems to be a sweet spot that does. It also must be run from [autoexec].

[cpu]
cycles = 100000

[dosbox]
vmem_delay = 8000

[autoexec]
mount c /home/user/dosdrive
c:
cd teddy
teddy

The cause is probably this line that gets run multiple times in VGA_Init. Reducing the delay to 1ms seems to fix it but it might also introduce regressions somewhere. Setting it to 0ms prevents the DOSBox window from ever showing. Default delay with these specific settings causes VGA_SetupDrawing (the function that VGA_StartResize calls after the delay) to get run too late to where the demo is already trying to read VGA registers.

dosbox-staging/src/hardware/vga.cpp

Line 329 in 2518288

VGA_StartResize();

[johnnovak]

So video init stuff... again... 🥶 😆

[johnnovak]

@PoulpSquad Edited the ticket description to clarify the edge case is in fact an emulator hard crash.

[PoulpSquad]

Thank you johnnovak.