|
From: simone m. <sma...@gm...> - 2010-03-06 16:19:27
|
Hi everyone, I am new to valgrind and tried to find an answer in the valgrind forum search; apologies if this was asked before. My code written in C was giving memory allocation problems so that I started using valgrind to track my memory. Specifically, to be sure of what was going on I first commented all lines except for those of declaration (how can I send lines of code to this mailing list). Although I am not explicitly allocating any memory (not with malloc, calloc, or other mean), I obtain this: malloc/free: 9 allocs, 0 frees 9 changes and increases by uncommenting the following lines one by one. Can anyone help me understand where this leak is occurring? Thank you in advance, Best |
|
From: Tim P. <ec...@ec...> - 2010-03-07 05:14:31
|
On Sat, 2010-03-06 at 17:19 +0100, simone marras wrote: > Hi everyone, > > I am new to valgrind and tried to find an answer in the valgrind forum > search; apologies if this was asked before. > > My code written in C was giving memory allocation problems so that I > started using valgrind to track my memory. > Specifically, to be sure of what was going on I first commented all > lines except for those of declaration (how can I send lines of code to > this mailing list). > Although I am not explicitly allocating any memory (not with malloc, > calloc, or other mean), I obtain this: > > malloc/free: 9 allocs, 0 frees > > 9 changes and increases by uncommenting the following lines one by one. > > Can anyone help me understand where this leak is occurring? You are probably using malloc(), just not knowingly. Even primitives in libc like getpw* allocate a re-usable structure with no obvious means to free it. There is a difference between leaking once, and leaking. I.e, subsequent calls to getpw* will not allocate a new structure or lose the pointer to the existing one, they will use the one that exists. I recommend compliling your code with optimizations turned off and debugging turned on, you should then be able to see the symbols that last used the pointers being referenced, and find out if indeed they are leaking. If they are still accessible upon termination, they aren't 'technically' being leaked. Cheers, --Tim > > Thank you in advance, > Best > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: simone m. <sma...@gm...> - 2010-03-07 14:41:54
|
Hi Tim, Thanks for helping. I will check my compilation with your suggestions. I appreciate it; All the best, Simone On Sun, Mar 7, 2010 at 6:13 AM, Tim Post <ec...@ec...> wrote: > On Sat, 2010-03-06 at 17:19 +0100, simone marras wrote: >> Hi everyone, >> >> I am new to valgrind and tried to find an answer in the valgrind forum >> search; apologies if this was asked before. >> >> My code written in C was giving memory allocation problems so that I >> started using valgrind to track my memory. >> Specifically, to be sure of what was going on I first commented all >> lines except for those of declaration (how can I send lines of code to >> this mailing list). >> Although I am not explicitly allocating any memory (not with malloc, >> calloc, or other mean), I obtain this: >> >> malloc/free: 9 allocs, 0 frees >> >> 9 changes and increases by uncommenting the following lines one by one. >> >> Can anyone help me understand where this leak is occurring? > > You are probably using malloc(), just not knowingly. Even primitives in > libc like getpw* allocate a re-usable structure with no obvious means to > free it. > > There is a difference between leaking once, and leaking. I.e, subsequent > calls to getpw* will not allocate a new structure or lose the pointer to > the existing one, they will use the one that exists. > > I recommend compliling your code with optimizations turned off and > debugging turned on, you should then be able to see the symbols that > last used the pointers being referenced, and find out if indeed they are > leaking. If they are still accessible upon termination, they aren't > 'technically' being leaked. > > Cheers, > --Tim > >> >> Thank you in advance, >> Best >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- Simone Marras, Ph.D. candidate Barcelona Supercomputing Center Universitat Politecnica de Catalunya Avd. Diagonal 647, Edificio H, planta 10 Barcelona, 08028 SPAIN Tel.: (+34) 93 4011744 web: www.cranfield.ac.uk/~c086030 |