Leaking MediaPlayer causes Win64 crashes #97
Comments
|
My guess is VS only attempts to kill the main thread, and the other ones just die on their own (well, unmanaged threads probably). You're essentially killing the process without closing the mixer, so this is expected. That NullReferenceException report is stupidly useless without a trace. Are you absolutely sure that XNA4 is okay with your code? The more issues I hear on this, the more I suspect that WMP would leak with your engine. |
|
How well does this project work on OSX/Linux? At least if it happens on other platforms it would verify that it's a generic lib problem rather than something Win32 needs to deal with. |
|
Ok so last night I thought as to why I am getting all these odd disposing issues, I am using 64-bit binaries if that changes anything? I am also using the preview build of sdl2_mixer.dll (I thought we were supposed to use that right?). Ill switch to 32-bit right now. I'd also like to point out that the only other MediaPlayer things I am touching other than MediaPlayer.Play() is MediaPlayer.Volume. |
|
Strange, I've actually not looked at anything 64-bit on Windows. I know 64-bit Linux is okay, and OSX is still limited to 32-bit... no idea how well .NET 64-bit works. The only MG-SDL2 title I've got where Windows is involved is Fez, and that one's currently 32-bit only. As long as you're using consistent architectures it should be okay, but for .NET (or just Win32 in general) you may just want to stick with 32-bit bins. |
|
Ok, I was right. No problems with 32-bit binaries. Thats a bumber though, one of the reasons I'm not using just original XNA4 on PC is so I can have access to 64-bit (and .net 4.5.). What differences could there be between 32-bit and 64-bit, I mean there are x64 sdl2_mixer libraries and associated files? |
|
To tell you the truth, I'm not sure. Particularly for Windows. Considering it works with 64-bit Linux, I'm wondering if something else is going on in there. This is where a background in low-level programming/debugging comes in handy, and Windows is my weakest platform. Maybe it's how the .NET assemblies are being built? I know Windows cares a lot more about the architecture target than Mac/Linux do (I just build my games as x86 and it's fine on both). Maybe SDL2# needs an explicit 64-bit target to deal with Windows? 🤷 Also keep in mind that a lot of those features are not available on other platforms (Mac especially), so you'll probably want to avoid the bleeding edge when it comes to the .NET features (and architecture targets) you use. |
|
SDL 64-bit I think works alright on Windows, the only problem it has is the several odd MediaPlayer issues. Maybe these won't be issues anymore once someone makes the vorbis port? |
|
That would definitely resolve it, but I suppose it's still concerning that Win64 exhibits this problem with SDL2_mixer. I don't see anything in the SDL2 Bugzilla or the Hg log that suggests any problem is known, so either there's something wrong with my SDL2_mixer interop or SDL2_mixer Win64 has an issue of its own. If you can, see if upstream Hg SDL2_mixer fixes it. For all I know, the binary could just be a dud. Also, try tracing all of the Song method calls... for all I know there's a call being done out of order that SDL2_mixer can't handle, though I try to limit mixer calls overall (grumble, threads). |
|
Yep, will do. Also what happens on x64 MacOSX, is it similar problems? Maybe you should create a issue for that as well? |
|
OSX doesn't even have a 64-bit Mono runtime yet. :P
|
|
Haha, I see. |
|
Okay well I switched to 32-bit for the time being, more bad news but, even though the end-of-song NullReferenceException is gone the "leak" warning is still there when I call Game.Exit(). Is fez on windows using .ogg files for sounds? Just like before on 64-bit, #98 fixes this, but I don't want you to accept that PR if you feel it is unnecessary. This is the best stack trace I could get:
My own global exception handler for the game writes this down as a NullReferenceException in the logs as: Unhandled exception at: 9/06/2013 3:54:02 PM, on thread: Main Thread. Fatal: True I am so lost... I'm doing nothing significant with MediaPlayer and if Fez reports no problems with song on Windows then what? This error does not happen if I were to close the game quickly after it started (within the first 10 seconds), after woods its doomed and always results in this. |
|
Wow, that's actually an interesting trace. It suggests that Song.closeMixer
|
|
http://www.libsdl.org/projects/SDL_mixer/docs/SDL_mixer_12.html Was just reading it. It mentions that "After calling this all audio is stopped, the device is closed, and the SDL_mixer functions should not be used." Makes me wonder why MediaPlayer.Stop() needs to be called in the first place then. |
|
After reading through some of the SDL_Mixer docs and looking at Song.cs I am so surprised this is even happening (I never realized how high level SDL/SDL_Mixer was haha, makes me want to learn C++). I'm probably going to do a variety of tests tomorrow on computers other than just my desktop as well. I'll also try create a test case that can create the problem. |
|
Does adding |
|
Ha, turns out I was a big liar: there is a 64-bit OSX runtime, as long as you're smart and stay away from System.Windows.Forms and MonoMac. Still, though. |
|
Ok, well, I downloaded the updated SDL_Mixer libraries and now I cannot get sound to play at all. I tried looking into why this is happening and I cant figure it out, nothing looks too significant on the SDL_Mixer change log. If I go back to the older SDL_Mixer libraries the sound works but the several crashing issues are back. My laptop reports exactly the same things. For now I am just going to disable SDL_Mixer entirely (thanks for that by the way - its not a required dependency anymore). I want to get back actually developing my game because for now I am over these SDL_Mixer issues and have not made much progress otherwise. By the time I actually "need" to play songs when my game is closer to release I will probably come back here, maybe others will report the same thing by then. I'm sure as heck still going to be using MonoGameSDL though, I love it and its in a much better state than WindowsGL/WindowsDX (MonoGame's WinDX is still unfinished and has been for 6 months...) If I come along any other issues I will be sure to post them here, Ill post if I end up getting SDL_Mixer working as well. Thanks for the help flibitijibibo :) |
|
Hm, wondering if your SDL2_mixer build missed Vorbis support, but the VCproj files should include it... Ah well. Hoping we find a real Vorbisfile# at some point, rather than that thing I found in the dumpster. Glad the rest of MG-SDL2 works though! |
|
@flibitijibibo |
|
Ah, good. Will be nice that this works with the 2.0 release, then. :D |
Ok so I recently just redowloaded the repo and the memory leaking error is back:
A callback was made on a garbage collected delegate of type 'SDL2#!SDL2.SDL_mixer+MusicFinishedDelegate::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.
When I was testing the MediaPlayer changes before I had my SDL_GamePlatform Exit method as follows.
If the Media.MediaPlayer.Stop(); is not there in the Exit (like it is now) method I receive the "passing delegate" error when calling Game.Exit() just like before. Ill think submit a PR for that in a moment.
I also submitted this issue for two other reasons as well.
When terminating the process through visual studio I get the same "passing delegate" message, how can a process termination result in a error/warning?
Finally (another MediaPlayer issue hehe), when a playing song sucessfully ends I get a untraceable NullReferenceException.
The text was updated successfully, but these errors were encountered: