Error message after closing application with SFML objects

[GaborKovacs]

Hi!

I'm using the .NET binding of SFML 2.0.

My application has a  class (a Windows.Forms.Form-based dialog) which contains the following SFML members:

Code: [Select]

private SoundBufferRecorder sBufRecorder = new SoundBufferRecorder();
private Sound sound = new Sound();

If I run the app and open this dialog at least once (and therefore the objects are created) I get the following error message after the application closes:

The instruction at "0x04b053cc" referenced memory at "0x05c1be80". The memory could not be read.

This happens whether or not I dispose of the objects explicitly.

The error goes away, if I do not actually create the objects (leave them as null):

Code: [Select]

private SoundBufferRecorder sBufRecorder;
private Sound sound;

but if either one of the two objects is created, the error message appears.

Could this have something to do with the CLR finalizer finding these objects in an invalid state?

Interestingly, I do not get the error message when I run the application in debug mode from the VS C# 2010 Express IDE.

The error occurs, however, if I run the exe in either the bin/Debug or the bin/Release folder, or publish and install the application with ClickOnce.

I've been wondering if you can give me a hint as to what might cause this problem, and how I could get rid of it.

Thanks in advance,

Gabor

[Laurent]

I have no idea, sorry :?

[GaborKovacs]

Thanks, anyway.

I've tried two things so far:

I put the Application.Run(...) call in a try/catch block, but it did not catch the exception, so it appears the problem occurs during CLR cleanup after the the application has shut down. So I though it might be related to the finalization of SFML objects.

I also tried calling GC.SuppressFinalize(...) after disposing of the relevant objects, but again it didn't help.

If this problem has never come up in native C++ or C applications, I think it might have something to do with the .NET binding handling unmanaged code. I've looked at the binding files and see nothing suspicious there, although I have to admit I'm not an expert in low-level .NET issues...

Gabor

[Laurent]

Hum I forgot about it, but it is actually a known bug in SFML (C++):
https://github.com/SFML/SFML/issues/30

[GaborKovacs]

All right, thanks.

Until the bug is fixed, is there a workaround so that my app exits in a more elegant way for the time being?

Gabor

[Laurent]

I don't think there's a workaround to avoid that.

[GaborKovacs]

Well, in that case, I'll go back to version 1.6 until this is fixed. Am I right in assuming that SFML 1.6 does not have this bug?

You say in your github post that you plan to fix this for version 2.x.

I think this should really be put right in the first official release of SFML 2.0, since there is no way to prevent the AudioDevice destructor from being called, so anyone using the SFML audio library will run into this issue (at least on some systems).

You said in the post that fixing this problem is not top priority for the time being; is that because it only and specifically affects XP users?

I think SFML is cleanest and most intuitive multimedia API I've ever seen (and it seems I'm not alone with this opinion), so I would very much welcome a robust and stable version 2.0 I could work with.

Thanks for all the effort you've put in this project so far.

Gabor

[Laurent]

Am I right in assuming that SFML 1.6 does not have this bug?

I'm not sure :?

I think this should really be put right in the first official release of SFML 2.0, since there is no way to prevent the AudioDevice destructor from being called, so anyone using the SFML audio library will run into this issue (at least on some systems).

It is an important bug, but SFML 2 has been started 3 years ago and I'd really like to release it one day. It's better to have a buggy SFML 2.0 than no SFML 2.0 at all, isn't it?

You said in the post that fixing this problem is not top priority for the time being; is that because it only and specifically affects XP users?

Nop, it's because it doesn't block the release (doesn't impact the public API).

I think SFML is cleanest and most intuitive multimedia API I've ever seen (and it seems I'm not alone with this opinion), so I would very much welcome a robust and stable version 2.0 I could work with.

A new major version is never stable. It brings a lot of design and API changes, so you can't expect it to be robust. That's what minor revisions are for. SFML 2.9 will be robust. Not SFML 2.0.

[GaborKovacs]

Thanks! Funny I've never thought of versions that way but I'll bear that in mind!

Gabor