Is this a bug or intended? Memory management issue

[wqking]

COpenGLFBODepthTexture is inherited from ITexture, which is inherited IReferenceCounted.
And COpenGLFBODepthTexture holds a pointer to IVideoDriver, however, it doesn't grab the Driver.

So if I call driver.addRenderTargetTexture, and store the returned ITexture to somewhere, and I call grap on it.
Assume the object freeing order is not guaranteed, so if I "drop" and free Driver first, and then call ITexture::drop, since COpenGLFBODepthTexture doesn't grab the driver and the driver is already freed, COpenGLFBODepthTexture will try to access a dangling driver pointer in its destructor, which causes crash.

So my question is,
Is it intended that COpenGLFBODepthTexture doesn't grad Driver? To avoid cycling reference? Or it's a bug?
If it's not a bug, does it mean we must enforce the order of freeing object, such as a video driver, or the device, must be free at the last? But that's not quite reasonable, because in a reference count based memory management, we should not assume any object freeing order.

Thanks

[hybrid]

Yes, sometimes internal usage of such pointers is not properly grab'ed, which is usually a bug. Since these helper textures were not properly integrated into the ressource system, it might have been a problem with the proper release schedule, but I don't remember any such cases here. So I guess it's just missing.

[wqking]

Thanks for the clarify.
I changed my code to workaround those kind of bugs.

[chronologicaldot]

Is that going to be changed in the future or would changing that hamper its primary usage?