~WildMidiSong() causes heap corruption about opentesarena

[Ragora]

I'd debug it if my anything worked. I'm running the same WildMIDI version but the playback still doesn't work. I'd guess that if mSong wasn't just somehow nullptr at that point, it would potentially be an issue in WildMIDI.

[afritz1]

Is your soundfont path in options.txt set correctly? I'm using the freepats .zip package from here.

[Ragora]

Looks like it's probably working now, just ran into the issue from #24 though. Time to fix that assertion!

Edit Works after that, let me attach the debugger and see what's going on.

Looks like nothing is wrong here, process is running fine. I'll set an explicit breakpoint on the destructor and see if there's anything amiss. But it looks like nothing weird is going on.

[afritz1]

If I comment out WildMidi_Close(mSong);, then the program runs like normal and plays the music as intended, but it's obviously not closing the MIDI tracks then.

However, with WildMidi_Close(mSong) commented, Visual Studio then breaks at WildMidi_Shutdown() in ~WildMidiDevice() on application exit.

I tried getting the return code from WildMidi_Close(mSong), but the debugger can never get that far.

I wonder if this could be at all related to using a newer MSVCR__.dll than @psi29a's recommended MSVCR80.dll for WildMIDI (since MSVCR80.dll is intended for Visual Studio 2005).

[Ragora]

I would see where it is breaking. You should be able to at least see what binary blob it halted in (a DLL name in the call stack or something). You could build WildMIDI as a debug library and link that so you can better debug what is going on as then it will have symbols to properly debug WIldMidi.

[afritz1]

Well, I was able to build wildmidi_dynamic.dll and its associated debug files, and after putting them in the OpenTESArena library folder, the program doesn't have any trouble anymore with WildMIDI. Strange.