no-reply@allegro.cc (thebignic) — Wed, 26 Sep 2012 04:14:57 +0000

I'm doing some memory leak analysis on my iOS device and so far so good, with the exception of a leak reported from al_fopen_interface (3 times during an 8 minute test run of my app.)

Seems like a pretty simple routine. Not sure whats leaking here?
Very confused.

#SelectExpand
 16ALLEGRO_FILE *al_fopen_interface(const ALLEGRO_FILE_INTERFACE *drv,
 const char *path, const char *mode)
 18{ 
 ALLEGRO_FILE *f = NULL;
 
 ASSERT(drv);  
 ASSERT(path);
 ASSERT(mode);
 
 if (drv->fi_fopen) {
    f = al_malloc(sizeof(*f));
    if (!f) {
       al_set_errno(ENOMEM);
    }
    else {
       f->vtable = drv;
       f->userdata = drv->fi_fopen(path, mode);
       f->ungetc_len = 0;
       if (!f->userdata) {
          al_free(f);
          f = NULL;
       }
    }
 }
 
 return f;
 42}

Am I not cleaning up the returned ALLEGRO_FILE object afterwards? Does al_fclose() not cleanup the object?

Would rather not have any leaks if submitting to AppStore... I've heard they can be pretty particular...

no-reply@allegro.cc (Trent Gamblin) — Wed, 26 Sep 2012 04:52:08 +0000

Memory leaks reported by the "Leaks" tool in instruments (and anything else really, like valgrind) report the source of the allocated memory, not where the "leak occurred" which would probably when the last reference to allocated memory is lost. The routine looks ok to me. If you're sure you're calling al_fclose on ALL handles returned from this then the leak may be in drv->fi_fopen in your implementation.

EDIT: it could also be your fclose implementation or somewhere else in your interface.

[A5] Memory Leak - al_fopen_interface