# 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;
BindTexture();
stbi_image_free(m_imageData_cch);
}

{
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 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?

##### Share on other sites

Do you ever release m_textureID?

##### Share on other sites

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 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 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 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 on other sites
36 minutes ago, antoniorv6 said:

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

Not really, no.

##### 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

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 15
• 12
• 9
• 11
• 15