Textures aren't handled by the Obj-c runtime, so leaks doesn't know anything about them. You have to use another tool.
In Xcode start a new project using the OpenGL template. Search the method that updates/draws the scene and add this code to its end:
static int tick = -1;
static GLuint tex[5];
if (tick++ < 0)
for (int f = 0; f < 5; f++)
tex[f] = 0;
tick = tick % 5;
if (tex[tick]) {
glDeleteTextures(1, &tex[tick]);
tex[tick] = 0;
} else {
glGenTextures(1, &tex[tick]);
glBindTexture(GL_TEXTURE_2D, tex[tick]);
char *mem = malloc(1024 * 1024 * 4);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA,
1024, 1024, 0, GL_RGBA, GL_UNSIGNED_BYTE, mem);
free(mem);
}
The code generates and destroys five textures using OpenGL Commands. Build it and run it once on your device to make sure it is installed. Don't worry about the chugging.
Now open instruments and start with the blank template for the iPhone. Open the library and drag the Memory Monitor to the window. Click on the information disclose button and uncheck everything but "Physical Memory Free". Now select to launch the binary on your iphone to start recording. You should see staircase pattern going up/down depending on when Instruments tries to sample the application. While the program is running you can see all the active processes with the column "Real Memory", showing actual memory usage.
In my tests, this example consumes between 25MB to 3MB depending on the moment of the memory sampling. This is with a second generation iPhone and SDK 3.1. If you have a 2.x SDK you have to search for the GART Resident Object Size in the normal OpenGL monitor. See http://blog.zincroe.com/2009/04/how-to-check-iphone-texture-memory-usage-with-instruments/ for further reference.
In any case, the memory jumping up and down proves that glDeleteTexture() does its work as advertised.