# glDeleteTextures Memory Leak
**URL:** https://forums.imgtec.com/t/gldeletetextures-memory-leak/3914
**Category:** Uncategorized
**Created:** [April 16, 2024, 1:30am UTC](https://forums.imgtec.com/t/gldeletetextures-memory-leak/3914 "2024-04-16T01:30:44Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@axel](https://forums.imgtec.com/u/axel)
#### Post date: [April 16, 2024, 1:30am UTC](https://forums.imgtec.com/t/gldeletetextures-memory-leak/3914/1 "2024-04-16T01:30:44Z")
Hi Experts,
Hardware:BXS 4-64 MC1
I found a memory leak problem about texture load in the opengl driver, below is my test
We have 4 ASTC image, every ASTC\<100k, test case is:
step1: glGenTextures
step2: glCompressedTexImage2D
step3: render
step4: glDeleteTextures
Complete 4 steps in a sec and repeat 600 times, we will see glerror 505 (memory leak) reported
I make sure I released the texture resources normally, It seems that glDeleteTextures just tells the opengl driver not to use the texture, but it does not release the resources immediately.
But even so, I don’t know when it will be released. Do you know how to force the release of resources, or have you encountered similar problems?
---
### Author:  [@AlejandroC](https://forums.imgtec.com/u/AlejandroC)
#### Post date: [April 18, 2024, 2:01pm UTC](https://forums.imgtec.com/t/gldeletetextures-memory-leak/3914/2 "2024-04-18T14:01:30Z")
Hi axel,
After consulting the OpenGL ES Driver Team, the OpenGL and OpenGL ES specifications mention that _ **the underlying object will not be deleted until it is no longer in use** _. Deletion is managed in a separate thread.
For your code to work correctly, you should use sync objects (see [Sync Object - OpenGL Wiki](https://www.khronos.org/opengl/wiki/Sync_Object) ). One option is to use a Fence sync object after the `glDeleteTextures` call. The sync object will be added to the command stream on creation. Later you can use `glWaitSync` or `glClientWaitSync` to know when the fence has been signaled, and then you will have the certainty from the CPU side that the `glDeleteTextures` call was completed. You should also keep track on how much GPU memory you are using.
Best regards,
Alejandro
---
### Author:  [@axel](https://forums.imgtec.com/u/axel)
#### Post date: [April 19, 2024, 12:57am UTC](https://forums.imgtec.com/t/gldeletetextures-memory-leak/3914/3 "2024-04-19T00:57:29Z")
Hi AlejandroC,
Thanks for your reply!
I found another phenomenon. Please help to confirm whether it is normal.
Old platform: SGX544
step1: id1 = glGenTextures()
step2: glCompressedTexImage2D
step3: render
step4: glDeleteTextures(id1)
step5: id2 = glGenTextures()
In this test case, we print the id, id1 == id2
Our new platform: BXS 4-64 MC1
step1: id1 = glGenTextures()
step2: glCompressedTexImage2D
step3: render
step4: glDeleteTextures(id1)
step5: id2 = glGenTextures()
In this test case, we print the id, id1 != id2, id2 always a new id
I am not sure if this is normal, it’s seems id1 is not released
---
### Author:  [@AlejandroC](https://forums.imgtec.com/u/AlejandroC)
#### Post date: [April 19, 2024, 10:05am UTC](https://forums.imgtec.com/t/gldeletetextures-memory-leak/3914/4 "2024-04-19T10:05:57Z")
Hi axel,
Thanks for your question.
The drivers in SGX544 and BXS 4-64 MC1 are most likely different. OpenGL IDs can be reused. For the case of BXS 4-64 MC1 having `id1 != id2`, it might mean the texture generated in step1 is still not released. I recommend you to look into sync objects as described in my previous message if you want to know when the command `glDeleteTextures(id1)` from step4 has been completed.
Best regards,
Alejandro