#10332 closed defect (fixed)

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

Reported by: g5ppc Owned by: criezy
Priority: blocker Component: GUI
Keywords: Cc:


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.

Change History (8)

comment:1 Changed 16 months ago by g5ppc

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

Last edited 16 months ago by g5ppc (previous) (diff)

comment:2 Changed 16 months ago by 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.

comment:3 Changed 16 months ago by criezy

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

comment:4 Changed 16 months ago by 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.

Last edited 16 months ago by csnover (previous) (diff)

comment:5 Changed 16 months ago by g5ppc

I just tried Torin with high-quality scaling unchecked in the Torin game settings, but it still crashed in that spot. The start screen does actually display, so it might be a little later than you are thinking.

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.

Last edited 16 months ago by g5ppc (previous) (diff)

comment:6 Changed 16 months ago by 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!

comment:7 Changed 16 months ago by g5ppc

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

comment:8 Changed 16 months ago by csnover

Owner: set to criezy
Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.