|
|
|
This thread is locked; no one can reply to it.
|
| [A5] Memory Leak - al_fopen_interface |
|
thebignic
Member #14,419
July 2012
|
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? 16ALLEGRO_FILE *al_fopen_interface(const ALLEGRO_FILE_INTERFACE *drv,
17 const char *path, const char *mode)
18{
19 ALLEGRO_FILE *f = NULL;
20
21 ASSERT(drv);
22 ASSERT(path);
23 ASSERT(mode);
24
25 if (drv->fi_fopen) {
26 f = al_malloc(sizeof(*f));
27 if (!f) {
28 al_set_errno(ENOMEM);
29 }
30 else {
31 f->vtable = drv;
32 f->userdata = drv->fi_fopen(path, mode);
33 f->ungetc_len = 0;
34 if (!f->userdata) {
35 al_free(f);
36 f = NULL;
37 }
38 }
39 }
40
41 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...
|
|
Trent Gamblin
Member #261
April 2000
 |
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.
|
|
|
