How does SFML handle deletion?

[RixCoder]

I created a resource manager in which I have my own templated new function that basically returns a pointer to the created object and stores the pointer of it in a list. in the resource manager's destructor it goes through the list of pointers it stored and deletes them all.

Problems are arising now that im crashing on exit. The last thing in my call stack is this:

Code: [Select]


> Jumpstart.exe!std::_Tree<std::_Tset_traits<sf::ResourcePtr<sf::Image> *,std::less<sf::ResourcePtr<sf::Image> *>,std::allocator<sf::ResourcePtr<sf::Image> *>,0> >::_Eqrange(sf::ResourcePtr<sf::Image> * const & _Keyval=0x0079d7d0)  Line 1133 + 0x8 bytes C++

EDIT: scratch that, even manual calls make it crash =p Is the resourcePointer generated for images and sound buffers self-cleaning?

Also is guessing theres no leaks coming out of sfml though CRT leak checking still reports a couple tiny leaks on exit even though i fully delete all new objects created. Any ideas?

[Laurent]

What the hell are you trying to do with a container of sf::ResourcePtr<sf::Image>* ??

[RixCoder]

I don't even have one =p

I've been working on the issue a lot and ive narrowed it down to the observer's resource pointers of a specific image going to 0xfeeefeee on me before deletion even occurs. The image* has a valid address as well as the observers but all the observers myResource evaluate to feeefeee.

This doesn't seem to be a problem until it reaches an object that has 20+ observers attached and than it will crash upon deletion.

the crash window described it as :
Windows has triggered a breakpoint in Jumpstart.exe.

This may be due to a corruption of the heap, which indicates a bug in Jumpstart.exe or any of the DLLs it has loaded.


Also in the output window:
The thread 'Win32 Thread' (0xc70) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x174) has exited with code 0 (0x0).
HEAP[Jumpstart.exe]: HEAP: Free Heap block 1102c510 modified at 1102c75c after it was freed

[RixCoder]

After looking at this for a while I don't think its an sfml problem, probably just something weird going on within allocation for my object cacher.

[Laurent]

I don't even have one =p

I've been working on the issue a lot and ive narrowed it down to the observer's resource pointers of a specific image going to 0xfeeefeee on me before deletion even occurs

Ah sorry, I thought it was from your own code. You should have added the rest of the call stack

Memory corruption can happen when you mix debug and release configurations, you can check that.

Otherwise I have no idea about what's going on.

[RixCoder]

I seemingly fixed the issue but now the exe hangs in the background after "closing" to which I have no idea whats causing that. I try to track it through the debugger and it steps through all destructors fine but than goes into assembly and thats where it just idles.

This simple thing is turning into something maddening =(

[phear-]

could you post the assembly?

[RixCoder]

Ok so the problem boiled down to something I guess is sort of a part of sfml. Is that If i delete sprite objects and sound objects BEFORE deleting their respective Image* and soundbuffer* it was causing problems when it had to detach the observers.

Switching the order to deleting the image and soundbuffers first before deleting the rest of the objects did the trick.

EDIT: also the not closing part was due to an infinite loop that came about from a commenting out frenzy =p

[Laurent]

The problem appears only with sounds / sound buffers. The bug has already been reported and added to the task list