I am trying to do some wrapping of the CSFML derelict bindings to classes however when i use the CSFML methods to destroy the objects it causes a crash.

I have made a post in the SFML>D forum because they have syntax highlighting for D so this kind of post looks nicer but the link is here:

http://en.sfml-dev.org/forums/index.php?topic=10005.0

There is a minimal code example there and a better explanation.

Can anyone help me with why this is happening?

On Sunday, 16 December 2012 at 14:42:57 UTC, Nekroze wrote:
> I am trying to do some wrapping of the CSFML derelict bindings to classes however when i use the CSFML methods to destroy the objects it causes a crash.
>
> I have made a post in the SFML>D forum because they have syntax highlighting for D so this kind of post looks nicer but the link is here:
>
> http://en.sfml-dev.org/forums/index.php?topic=10005.0
>
> There is a minimal code example there and a better explanation.
>
> Can anyone help me with why this is happening?

Why would you call a destroy() on a this object inside ~this()? And accessing allocated by GC objects inside destructor is not safe, because they may be collected before running the destructor.

On Sunday, 16 December 2012 at 14:59:32 UTC, Maxim Fomin wrote:
> On Sunday, 16 December 2012 at 14:42:57 UTC, Nekroze wrote:
>> I am trying to do some wrapping of the CSFML derelict bindings to classes however when i use the CSFML methods to destroy the objects it causes a crash.
>>
>> I have made a post in the SFML>D forum because they have syntax highlighting for D so this kind of post looks nicer but the link is here:
>>
>> http://en.sfml-dev.org/forums/index.php?topic=10005.0
>>
>> There is a minimal code example there and a better explanation.
>>
>> Can anyone help me with why this is happening?
>
> Why would you call a destroy() on a this object inside ~this()? And accessing allocated by GC objects inside destructor is not safe, because they may be collected before running the destructor.

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?

On Sunday, 16 December 2012 at 15:21:46 UTC, Nekroze wrote:
> On Sunday, 16 December 2012 at 14:59:32 UTC, Maxim Fomin wrote:
>> On Sunday, 16 December 2012 at 14:42:57 UTC, Nekroze wrote:
>>> I am trying to do some wrapping of the CSFML derelict bindings to classes however when i use the CSFML methods to destroy the objects it causes a crash.
>>>
>>> I have made a post in the SFML>D forum because they have syntax highlighting for D so this kind of post looks nicer but the link is here:
>>>
>>> http://en.sfml-dev.org/forums/index.php?topic=10005.0
>>>
>>> There is a minimal code example there and a better explanation.
>>>
>>> Can anyone help me with why this is happening?
>>
>> Why would you call a destroy() on a this object inside ~this()? And accessing allocated by GC objects inside destructor is not safe, because they may be collected before running the destructor.
>
> 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?

To me it makes sense to use the sfml objects destroy function when the my object gets destroyed regardless of when it happens.

It cant be that i have to have a separate destroy method for my class that i must manually use each time. kind of kills the point of having a GC then doesn't it?

Like i said sorry if i am being dim that just makes sense to me.

On Sunday, 16 December 2012 at 15:21:46 UTC, Nekroze wrote:
> On Sunday, 16 December 2012 at 14:59:32 UTC, Maxim Fomin wrote:
>> On Sunday, 16 December 2012 at 14:42:57 UTC, Nekroze wrote:
>>> I am trying to do some wrapping of the CSFML derelict bindings to classes however when i use the CSFML methods to destroy the objects it causes a crash.
>>>
>>> I have made a post in the SFML>D forum because they have syntax highlighting for D so this kind of post looks nicer but the link is here:
>>>
>>> http://en.sfml-dev.org/forums/index.php?topic=10005.0
>>>
>>> There is a minimal code example there and a better explanation.
>>>
>>> Can anyone help me with why this is happening?
>>
>> Why would you call a destroy() on a this object inside ~this()? And accessing allocated by GC objects inside destructor is not safe, because they may be collected before running the destructor.
>
> 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?

I do not know this library, but if you get InvalidMemoryOperationError it likely mean that you call in class dtor some function, which causes GC allocation. In your case it seems that you call sfImage_destroy(image) which might do such things.

On Sunday, 16 December 2012 at 17:14:55 UTC, Maxim Fomin wrote:
> On Sunday, 16 December 2012 at 15:21:46 UTC, Nekroze wrote:
>> On Sunday, 16 December 2012 at 14:59:32 UTC, Maxim Fomin wrote:
>>> On Sunday, 16 December 2012 at 14:42:57 UTC, Nekroze wrote:
>>>> I am trying to do some wrapping of the CSFML derelict bindings to classes however when i use the CSFML methods to destroy the objects it causes a crash.
>>>>
>>>> I have made a post in the SFML>D forum because they have syntax highlighting for D so this kind of post looks nicer but the link is here:
>>>>
>>>> http://en.sfml-dev.org/forums/index.php?topic=10005.0
>>>>
>>>> There is a minimal code example there and a better explanation.
>>>>
>>>> Can anyone help me with why this is happening?
>>>
>>> Why would you call a destroy() on a this object inside ~this()? And accessing allocated by GC objects inside destructor is not safe, because they may be collected before running the destructor.
>>
>> 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?
>
> I do not know this library, but if you get InvalidMemoryOperationError it likely mean that you call in class dtor some function, which causes GC allocation. In your case it seems that you call sfImage_destroy(image) which might do such things.

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.

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.

On Monday, 17 December 2012 at 04:40:39 UTC, Mike Parker wrote:
> 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.
>

[1]http://dblog.aldacron.net/forum/index.ph

On Monday, 17 December 2012 at 04:42:49 UTC, Mike Parker wrote:
> On Monday, 17 December 2012 at 04:40:39 UTC, Mike Parker wrote:
>> 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.
>>
>
> [1]http://dblog.aldacron.net/forum/index.ph

Sorry about not posting on the derelict forums, i cant remember exactly what happened but i made an account and it said i have to wait for authentication or something so i couldn't post... may have it confused with another forum but yeah will do in the future when i can post there.

Anyways so if i understand right the sfml objects wont delete themselves until the process exits right but what if i am in the middle of the process say in a game and i want to load another level i need to destroy the resources from the last level with the sfml destroy functions right. I just wanted that to be done automatically rather then having to have a destroy method that i must manually call from my class.

So what i am getting here is that either A: having it in the destructor will work solong as the GC cleanup is called before the end of main because that is when sfml is unloaded OR B: I just have to have a manual destroy method in my class too to release the sfml objects?

On 2012-12-17 07:45, Nekroze wrote:

> So what i am getting here is that either A: having it in the destructor
> will work solong as the GC cleanup is called before the end of main
> because that is when sfml is unloaded OR B: I just have to have a manual
> destroy method in my class too to release the sfml objects?

You cannot trust that the GC will collect at all. Although if the function pointers in the bindings are still active and you don't need to rely on the order of destruction you should be pretty safe, since your not destroying GC memory.

The safest is to either:

A. Manually call a destroy/delete function
B. Call a destroy/delete function in a scope(exit) block (basically the same as A)
C. Use a struct and call a destroy/delete function in its destructor.

-- 
/Jacob Carlborg