Resource leak on std::move to managed buffer.

[Megaxela]

If move one managed buffer (gl::vertex_buffer, gl::buffer, gl::texture etc.) to another managed buffer, target data will be leaked. (No glDeleteBuffers and etc. in move operator. Target Id will be lost.)

[acdemiralp]

Hey Alex, the ids should be setting to invalid_id on move see buffer for example:

buffer::buffer (      buffer&& temp) noexcept : id_(std::move(temp.id_)), managed_(std::move(temp.managed_))
{
#ifdef GL_CUDA_INTEROP_SUPPORT
  resource_ = std::move(temp.resource_);
#endif

  temp.id_       = invalid_id;
  temp.managed_  = false;
#ifdef GL_CUDA_INTEROP_SUPPORT
  temp.resource_ = nullptr;
#endif
}

[acdemiralp]

Ahh, after seeing the MR I see what you mean. The destructor is called upon the moved object after the move constructor. Which has invalidated the id, hence no deletion will occur.

There is no leak, and this is intentional, in order to preserve move semantics and make them identical for the CPU and the GPU. You do not reallocate but transfer the GPU reference to the new object. Note that the default constructor is not called within the move constructor, hence move does not allocate any GPU resource at all, it just transfers the existing resource onto itself.

Please correct me if I am wrong.

[Megaxela]

Yeah, sure, you right for move constructors, but what if I will create managed gl::buffer (with default constructor, for example) and then move another manager buffer into?

gl::buffer initialBuffer; // It's managed (glCreateBuffer was called)
gl::buffer secondBuffer; // It's managed (glCreateBuffer was called)
...
initialBuffer = std::move(secondBuffer); // operator=(gl::buffer&&) operator called. Now initialBuffers managed data was leaked, because it was not freed.

[acdemiralp]

You are correct. I am figuring out a fix.

[acdemiralp]

Solved in 2f08cf91069c8c3f37b0335e17d15d23ecc6b69d , thank you very much for detecting and fixing.