Access Violation in SFML 2.0 when destroying resources

[pdinklag]

Hey!

I've stumbled upon this wonderful multimedia library the other day and found that it featured most things which I would have had to implement by myself. Easy to use straightforward API and cross-platform, exactly what I need.

Unfortunately, there was no Java binding, and the one that had been started seems to be dead by now, so here I am writing my own which I may or may not release at some point - but more on that at another time.

I'm writing Java classes that are wrappers around their corresponding SFML classes. When such a Java class is instantiated, I call a native (C++) method that will create an SFML object (using "new") and store the pointer to it back into the Java object. When the Java object gets "finalized" (if you're not into Java: that's pretty much like destruction), I use "delete" to destroy the SFML object refered to by the pointer.

Consider this example of the Image class:

Code: [Select]


JNIEXPORT jlong JNICALL Java_org_sfml_Image_nativeCreate (JNIEnv *env, jobject obj) {
return (jlong)(new Image());
}

JNIEXPORT void JNICALL Java_org_sfml_Image_nativeDelete (JNIEnv *env, jobject obj) {
Image* ptr = PTR(Image);
if(ptr) delete ptr;
}
Note: "PTR" is a macro that retrieves the pointer in the Java object "obj".

When I started I wanted to make sure I'm working with a stable SFML, so I used SFML 1.6. Everything was working fine this way.

However, I have started to upgrade things to SFML 2 today and unfortunately that causes an access violation whenever a resource (Image, SoundBuffer, Font, etc.) gets destroyed. To track the problem down, I made a simple test application that will load an Image from a file and then destroy it.

The exception was this:

Code: [Select]

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5f0d530e, pid=1176, tid=1484

This was the stack trace:

Code: [Select]

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [OPENGL32.dll+0x530e]
j  org.sfml.Image.nativeDelete()V+0
j  org.sfml.SFMLNativeObject.finalize()V+45
v  ~StubRoutines::call_stub
V  [jvm.dll+0xecf9c]
V  [jvm.dll+0x1741d1]
V  [jvm.dll+0xed01d]
V  [jvm.dll+0xf5e2f]
V  [jvm.dll+0xf8b24]
C  [java.dll+0x2115]
j  java.lang.ref.Finalizer.runFinalizer()V+45
j  java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;)V+1
j  java.lang.ref.Finalizer$FinalizerThread.run()V+11
v  ~StubRoutines::call_stub
V  [jvm.dll+0xecf9c]
V  [jvm.dll+0x1741d1]
V  [jvm.dll+0xed167]
V  [jvm.dll+0xed1dd]
V  [jvm.dll+0x116290]
V  [jvm.dll+0x1d0414]
V  [jvm.dll+0x173e4c]
C  [msvcr71.dll+0x9565]
C  [kernel32.dll+0xb50b]

Apparently, something went wrong in opengl32.dll while destroying the object.
The only invocation of an OpenGL function inside the Image destructor that I found is this (Image.cpp line 88):

Code: [Select]

GLCheck(glDeleteTextures(1, &Texture));

I'm not sure what could possibly go wrong here. As mentioned, the Image object was created using "new" and destroyed using "delete", the image has been loaded from a jpg file. The OpenGL version on the Windows XP machine I'm developing on is only 1.4, but this was not a problem with SFML 1.6.

Do you have any idea what could be going wrong here?
Thanks a lot in advance!

[Laurent]

I think you should wait a little bit, I'll soon commit a fix about OpenGL context stuff, that could solve your problem.

[pdinklag]

It might be the context destruction after all, indeed.
Good to know then, I'll just ignore those for the time being then.