App crashes on close, or with MT-32 active at game start

[g5ppc]

When I use the daily win32 build, I get an app crash on every game just after the MT-32 screen text appears. This happens on both machines I tested(win7 x64 and win8.1 x64). Sometimes music actually begins (digital Sierra fanfare of torin's passage) before the crash.

I removed my scummvm.ini and added one game. That played. Then I enabled MT-32 Emulator on the MT-32 tab, and started that game. Crash.

Even with MT-32 disabled(default install), I get the same appcrash when I Alt-F4 to close Scummvm from the chooser/picker.

This started at least on 11/18-build, but I wasn't doing any active testing and just rolled back to my prior daily of 10/30, and assumed it was something that would be caught by someone else.

Windows says the module is SDL2.dll, and the exception offset is 0006c553.

[g5ppc]

I am currently using 2.0.0git48-g883fd87e8f from scummvm-win32.exe installer.

[csnover]

If I replace SDL2.dll with 2.0.7 from libsdl.org then the build crashes immediately on startup. I don’t have a Windows debugger at the moment (I’m working on this) but I guess there were some open questions about whether 6b4195a542083c97f696c843b9823d578b018996 was maybe breaking stuff, and that certainly seems to fit within your given date range. With regards to Torin, that point where it crashes is when the game switches to render in true colour mode (if you disable “Use high-quality video scaling” then it does not crash there). Once a debugger is put onto this issue there should be more useful information.

[criezy]

Commit 6b4195a has now been reverted. It might be worth testing again with the next daily build.

[csnover]

Upon further investigation, I cannot state definitively that the problems I am seeing are not simply errors caused by running in VirtualBox, which provides very incomplete graphics support. The 2.0.7 crash happens within a stack frame of VirtualBox’s OpenGL code, using ScummVM’s OpenGL renderer results in an invalid (white) texture when trying to render the true colour parts, and the “crash” of 2.0.4/2.0.5 that I see is actually ScummVM giving up when SDL won’t give it a true colour texture and exiting explicitly. So someone with unvirtualised Windows will need to look at this, not me, if the problem is not resolved by reverting 6b4195a.

[g5ppc]

I just tried Torin with high-quality scaling unchecked in the Torin game settings, but it still crashed in that spot.

I have been wondering if there is a commonality on my two systems, and VirtualBox would be one. No, they aren't virtual systems, but they both have VirtualBox installed. I looked at the sound drivers before filing the bug report, but couldn't see any filter driver on it from VBox.

[csnover]

OK, it definitely sounds like I am seeing phantoms due to trying to run ScummVM in VirtualBox. Thanks for verifying that. I don’t think that having VirtualBox installed has anything to do with the actual crashes you are experiencing.

The Kirben build is updated with criezy’s change, so please download it again and try and let us know the results. Thanks!

[g5ppc]

Can confirm the new daily build does not crash. wow.

[csnover]

Great! I’m mildly interested in knowing if we are doing something somewhere that is not locking surfaces correctly which is leading to the trouble, but not really interested enough to look into it since we’re not performance-constrained without RLE acceleration.