I guess you used the -v flag option with valgrind to get more verbose output. It's a long time since a don't use this tool but I remember it checks even FILE* variables pointing closed streams or any kind of pointers pointing freed memory areas. Could you mail the exit of valgrind execution??
Another possibility could be to run your program on a newer linux kernel machine. If valgrind doesn't find any memory leak I would bet for a out-of-your-program bug. Anyway, it's the memory still allocated after the end of the program execution??? I don't see the point of reading the file size inside the loop. Does the file change?? Looks it doesn't cause you open it with the "r" mode. If it doesn't, try to read the fileSize out of the loop. Maybe it's not the solution for the memory leak, but your program will probably be more efficient. Regards. Fernando. On Mon, Jun 21, 2010 at 18:47, Khoa To <[email protected]> wrote: > > I don't think we use afs file system. slabtop does not have > afs_inode_cache as one of its entries. > > > Regarding things that don't really make sense in sample code: > - In the real application, we're getting the file size by doing > fseek(ptr, 0, SEEK_END); > fileSize = ftell(ptr); // This line was omitted in > the sample code > fseek(ptr, 0, SEEK_SET); > - The "&&" was something that my internet browser did, it's supposed to > be just "&&" > - print("Success\n") instead of printf("Success") was a cut-n-paste error. > > Khoa. > > > > From: Stephan Wiesand <[email protected]> To: > [email protected] > Cc: Khoa To <[email protected]> Date: 06/21/2010 10:56 AM Subject: Re: Mem > leak with fopen/fseek/fclose ? > ------------------------------ > > > > > On Jun 21, 2010, at 3:12, Khoa To wrote: > > > I observed a memory leak (about 20 bytes per iteration) when I ran this > > > > simple program on my Scientific Linux 5.4 box (kernel version 2.6.18- > > 128.1.1.e15). > > Pretty old kernel (the one from the 5.3 initial release). What's the AFS > client version? (output of "rxdebug localhost 7001 -v") > > > What I did was noting the output of "free -m" before and after I ran the > > > > program (which loops for 300000). I observed a 6MB increase in memory use > > d. > > No error was printed during the run. > > > > If I comment out the 2 fseek statements, then I don't see any memory > > increase. > > Check the amount of memory used for afs_inode_cache before and after the > run (using slabtop). Does the difference account for the "leak"? > > > > The file size is about 700KB. > > > > I was wondering if someone can tell me if this is a known issue or if I'm > > > > doing something wrong. > > Well, the code below is not what you're actually running since amp is > undefined. And the whole test for the while() loop doesn't make too much > sense to me (although the first statement could probably simply be omitted). > > Regards, > Stephan > > > > > Thanks, > > Khoa. > > > > ======Source file, compiled with gcc========= > > > > #include <stdio.h> > > #include <errno.h> > > > > int main() > > { > > FILE * ptr = NULL; > > int count = 0; > > > > ptr = fopen("myBinaryFile","r"); > > while (ptr != NULL && count++ < 300000) > > { > > usleep(1000); > > > > if (fseek(ptr, 0, SEEK_END)) > > printf("Error 1: %d\n", errno); > > if (fseek(ptr, 0, SEEK_SET)) > > printf("Error 2: %d\n", errno); > > > > if (fclose(ptr)) > > break; > > > > usleep(10000); > > > > ptr = fopen("myBinaryFile","r"); > > } > > > > fclose(ptr); > > > > if (count >= 300000) > > print("Success\n"); > > > > return 0; > > } > > -- > Stephan Wiesand > DESY -DV- > Platanenallee 6 > 15738 Zeuthen, Germany > > > > > > > -- --------------------------------------------------------------------------------------------------------- Fernando Campos Del Pozo Becario Super-computación Departamento de Física Teórica Universidad Autónoma de Madrid Tlf.: +34-914974893 e-mail: [email protected] http://rincon.uam.es/dir?cw=999890136718750
