ITerrainSceneNode mem-bug??, cant remove it.HELP!!!

[bonsalty]

Thank you guys, you did a great job !
I like if somebody is conscientious , I would invite you for a beer if I could.

Code: Select all

driver->removeHardwareBuffer(node->getRenderBuffer());
node->remove(); 

Works excelent.

I havent tested the updateAllHardwareBuffers() , but the program would fill up the memory , crashing depending on the size of the map before killing the buffer.

[Nox]

would it be enought to check the referencecount of a IMeshBuffer? If the Link is getting updated it could check if the referencecount is equal to 1 => its the last owner => it can be deleted. Or missed i something?

[vitek]

would it be enought to check the referencecount of a IMeshBuffer

If the driver grabbed and dropped the IMeshBuffer pointers, then this is a possible solution. One very serious issue to consider is that there is no guarantee that an IMeshBuffer derived class is on the heap. If this were to happen, you could pretty much guarantee application crashes.

This results in (hopefully...) 60 times per second, resulting in about 5.5 minutes until deletion. Something which should be configurable, but not too far from a sensable value.

Unless the cached data can actually be reused, keeping it in a cache is useless and wasteful. Another issue to consider is that it _may_ result in incorrect behavior.

Consider the following scenerio. Application allocates a mesh buffer on the heap. Lets say that the mesh buffer resides in memory at address A. This mesh buffer is rendered. In the process, the driver creates a SHWBufferLink for it, and creates a map entry that maps A to that SHWBufferLink. Some time later the mesh buffer is deallocated. The SHWBufferLink for A remains in the map. A new SMeshBuffer is allocated, and that object happens to reside at the same address as the old mesh buffer. This is allowed. Now the map entry from A will map to the SHWBufferLink from the old mesh buffer.

It appears that this can happen, even though the author jumped through a bunch of hoops to avoid it (the changeID field in the vertex and index buffers and the changeID fields in the buffer link). Unfortunately, this additional code doesn't help if the changeID values happen to match, which seems to be a possible case.

Travis

[Nox]

If the driver grabbed and dropped the IMeshBuffer pointers, then this is a possible solution. One very serious issue to consider is that there is no guarantee that an IMeshBuffer derived class is on the heap. If this were to happen, you could pretty much guarantee application crashes.

A IMeshBuffer pointer is kept by the SHWBufferLink already, so this check wont the that problematic (or i got an to old irrlicht version).
You got a point with the non-heap objects but this could happen with every object which is a IReferenceCounted object like IMeshBuffer. So IReferenceCounted should never been allocated at the heap. But i see no way to deny this missuse.