Leak when allocating or deleting textures on Adreno 330


I think I have a similar problem to this one: 5305-A-Question-about-glTexImage2D()-and-using-memory (I’m not allowing to post the whole URL since this is my first post)
but the solution described there (using glBindTextures after a glDeleteTexture to force the texture memory to be freed) did not seem to work in my case, and the thread is closed, so I created this one.

We have a cross-platform game engine, which uses OpenGLES for its iOS and Android versions. Our games frequently create new textures and delete textures because of their nature (point&click games, every image has to be deleted then new ones be loaded at every scene change). We did not have any problem until we tested it on a Kindle Fire HDX, which holds an Adreno 330. The problem seems to exist also on the versions of the Galaxy S3 that holds an Adreno 330 (northern-american ones).

On this hardware, there seems to be a leak, either at texture allocation or deleting, that causes the application to crash every 10-15 minutes.

Basically, every time we know we will need a new texture, we generate a new texture ID:

glGenTextures(1, &mTexId);
glBindTexture(GL_TEXTURE_2D, mTexId);

after loading an image, we provide it to OpenGL:

glBindTexture(GL_TEXTURE_2D, mTexId);
case IF_R8G8B8A8:
    glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, img.bufferWidth(), img.bufferHeight(), GL_RGBA, GL_UNSIGNED_BYTE, buffer);

When we enter a new scene, the first thing we do is freeing everything we did in the previous scene, including textures:

glDeleteTextures(1, &mTexId);

I checked that the textures were deleted in the same thread as the one in which the egl context was made current, which seems like a frequent fix for this problem. Except that I’m not sure the whole textures are leaking (otherwise when leaving a scene I should have a 20MB leak, I never have more that a 5MB leak at once), and our engine is mostly single-threaded, so this is not likely to happen.

I tried to reuse texture IDs, or even keeping already allocated textures to use them for textures of the same size. The first solution did not make any difference, and I think I didn’t implement the second one carefully enough for it to work (this was supposed to be a last-minute fix… and the game in question uses textures of very varying sizes, so it might actually not be very efficient).

As I said, to this day, this problem only occurred on devices using an Adreno 330, so I suspect a bug in the driver. I already posted on the Qualcomm forums, but the answers are not frequent. Is there a known workaround for this kind of issue?

Thanks in advance for your answers,


After some further investigation, I’m not sure about a leak (since last time I learned to profile the Native Heap, the Java Heap and the PSS). There was some massive “leak” in the PSS, which was caused by the fact we use a single package for our assets inside our apk (storing each individual asset in the apk causes performance issues), and Android keeps each data read in RAM for further reads, which I “solved” by closing and reopening this asset from time to time.
This issue could only be seen in the PSS.

I didn’t see anything that looked like a leak in the Java Heap or the Native Heap.

Currently, I am suspecting that using textures of a size of 1024*1024 or more is unsafe because of this:
When I print native heap informations through getNativeHeapSize(), getNativeHeapFreeSize() and getNativeAllocatedSize(), getNativeHeapSize() is never the sum of getNativeHeapFreeSize() and getNativeAllocatedSize(), getNativeHeapFreeSize() is always around 2-4MB. When modifying the game’s data, the game doesn’t always crashes at the same point (I have to investigate exactly how much RAM it consumes each time it crashes to be sure). It always crashes during a call to glTexImage2D(). Has anyone experienced something like this?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.