Jump to content
  • Advertisement
antoniorv6

OpenGL Memory leak with OpenGL Textures

Recommended Posts

Hi. I am developing a sort of graphic engine for a project at the University and I have stepped into a problem that I don't really know how to interpret. I'll explain.

In our game engine, when you load a texture, you read it with the function that STB image library provides: stbi_load(), and then bind it. This is done by the following code:

void TResourceTexture::LoadResource(const std::string& c_resourceDocument_str)
{
    std::string l_assetRoute = "assets/" + c_resourceDocument_str;
    LoadFromSTBI(l_assetRoute);
    BindTexture();
    stbi_image_free(m_imageData_cch);
}

void TResourceTexture::LoadFromSTBI(const std::string& c_resourceDocument_str)
{
    m_imageData_cch = stbi_load(c_resourceDocument_str.c_str(), &m_width_i, &m_height_i, &m_bDepth_i, 3);
    if(!m_imageData_cch)
    {
        std::cout << "[ERROR] - Texture could not be found"<<std::endl;
        stbi_image_free(m_imageData_cch);
        return;
    }
}

void TResourceTexture::BindTexture()
{
    glGenTextures(1, &m_textureID);

    glBindTexture(GL_TEXTURE_2D, m_textureID);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, m_width_i, m_height_i, 0, GL_RGB, GL_UNSIGNED_BYTE, m_imageData_cch);

    glGenerateMipmap(GL_TEXTURE_2D);

    glBindTexture(GL_TEXTURE_2D, 0);
}

This works fine and does not give any problems. However, if I change the first line of LoadFromSTBI and the seventh of BindTexture() with these:

m_imageData_cch = stbi_load(c_resourceDocument_str.c_str(), &m_width_i, &m_height_i, &m_bDepth_i, 4);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, m_width_i, m_height_i, 0, GL_RGBA, GL_UNSIGNED_BYTE, m_imageData_cch);

Valgrind triggers me the following memory leak:

==5745==
==5745== 6,840 bytes in 1 blocks are possibly lost in loss record 137 of 140
==5745==    at 0x483777F: malloc (vg_replace_malloc.c:299)
==5745==    by 0x19A7A0AD: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x19A7A178: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x19A77FB6: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x19A781E2: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x19ACFC5B: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x6DD54FE: __pthread_once_slow (in /usr/lib/libpthread-2.28.so)
==5745==    by 0x19AD0266: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x19ADE107: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x199C658E: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x19A05B9E: ??? (in /usr/lib/dri/i965_dri.so)
==5745==    by 0x19A05EC0: ??? (in /usr/lib/dri/i965_dri.so)

I thought it was a memory leak related to hardware and graphic drivers, but while testing in other different device, it triggered again. Does anyone know what's going wrong with this change or if it has to be done anything extra if you are using this function in order to avoid this leaks?

Thank you in advance!

Share this post


Link to post
Share on other sites
Advertisement

Yeah, when I delete the texture, i do:

TResourceTexture::~TResourceTexture()
{
    glDeleteTextures(1, &m_textureID);
    m_textureID = 0;
    m_width_i = 0;
    m_height_i = 0;
    m_bDepth_i = 0;
}

 

Share this post


Link to post
Share on other sites

What about `m_imageData_cch`?

Also, don't forget that OpenGL rendering is asynchronous, so the deletion may not be immediate. Also, the driver may keep the memory allocated to manage textures for later reuse.

Share this post


Link to post
Share on other sites
1 hour ago, l0calh05t said:

What about `m_imageData_cch`?

Yeah, I free it at the last line of TResourceTexture::LoadResource().

1 hour ago, l0calh05t said:

Also, don't forget that OpenGL rendering is asynchronous, so the deletion may not be immediate. Also, the driver may keep the memory allocated to manage textures for later reuse.

Is it any way i can figure out it is doing so?

Share this post


Link to post
Share on other sites
Posted (edited)

Are you sure that

 m_width_i, m_height_i

pixel perfectly match the m_imageData_cch size and is no smaller, meaning m_imageData_cch contains only raster portion of picture after the library load?

It seems the library does not provide alpha channel from the picture, can you check the returned data size if it is there?

Edited by JohnnyCode

Share this post


Link to post
Share on other sites
36 minutes ago, antoniorv6 said:

Is it any way i can figure out it is doing so?

Not really, no.

Share this post


Link to post
Share on other sites

 

7 hours ago, JohnnyCode said:

Are you sure that


 m_width_i, m_height_i

pixel perfectly match the m_imageData_cch size and is no smaller, meaning m_imageData_cch contains only raster portion of picture after the library load?

It seems the library does not provide alpha channel from the picture, can you check the returned data size if it is there?

Alright, I will check it out. stbi_load should give the data correctly, you pass the reference and it gives you the value i has retrieved. Also, if you put a 4 in the last parameter, should return alpha channel. It works correclty that way, but it freaks me out why only in this case valgrind detects a memory leak. Even though I will reply later knowing the size of m_imageData_cch

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!