First, please take all Derelict trouble-shooting problems to the
Derelict forums[1]. I never check the sfml forums. I do check the
newsgroups regularly, but these newsgroups are not generally the
place to look for help with Derelict problems. Plus, by posting
in other places, you are making it more unlikely that future
users with the same problem will find an answer.
On Sunday, 16 December 2012 at 17:20:55 UTC, Nekroze wrote:
I am sorry if i am being dim but i thought that the sfml
objects are not GC objects so it will exist forever until i
call its destroy function so why cant this be done in the
destructor? Unless you mean the pointer is being destroyed
before the destructor is being called?
You are correct in that the sfImage instance is not GCed and will
continue to stay resident in memory. But *your* Image class *is*
GCed. You cannot, ever, rely on D destructors to clean up
external resources. This is because you have no idea when, if, or
in what order they will be called during runtime. They *will* be
called when the program exits and the GC cleans up, but that is
where you are running into your problem. See below.
sfImage_destroy is purely a binding to a c function in a dll.
It has no knowledge of the GC or anything which is why the
image will live forever unless i call that function.
SFML is a c++ OO based graphics library, in order to provide a
c binding they made a C wrapper around all the OO stuff so the
object, its all handled using C functions, needs to have its
destructor called manually with the C destroy functions. With
the D wrapper for this (Derelict3) there is no actual function
for these its just some kind of pass through binding to the dll
so the above, as far as i can understand, still holds true.
This is why i have come to the belief that i should be
perfectly able to call this destroy function in the destructor
because what i am calling destroy on is an object that is
created in C++ but accessed through C functions which have just
been imported and bound to D names.
You have to understand that Derelict is a dynamic binding and not
a static one. In this sort of binding, all of the functions you
call are actually function pointers. When you call
DerelictSFML2.load, Derelict is loading the shared library for
you and making sure the function pointers are pointing to the
write places. In a static binding where you would link with a
static library, a Windows DLL import library, or directly with an
shared object file on Posix systems, the shared library is loaded
automatically and you call the functions normally rather than
through pointers ("bound to D names", in other words).
Any call to load a library into memory should generally be
matched by a call to unload it. All Derelict bindings include a
module destructor that automatically unloads its shared library
at program exit. So here's what's happening to you. When your
main function exits, the runtime starts the cleanup process. It
runs the module destructors *before* cleaning up the GC. So
DerelictSFML2's module destructor is run, the CSFML2 library is
unloaded from memory, then after that the GC's cleanup begins
and, at some point, the destructor on your Image class instance
is called. Only now, when you call sfImage_destroy the library
was already unloaded by the module destructor so the function
pointer is no longer valid. Boom! You have a crash.
Perhaps it would be ok for me to remove the module destructors
and let the OS just free up the libraries when the process exits,
but I'm not going to do that. Regardless, it doesn't change the
fact that you should never, ever, ever rely on D class
destructors for this sort of thing.
