|
From: Bob R. <bo...@br...> - 2005-08-17 11:24:39
|
On Sat, Aug 13, 2005 at 06:39:38PM -0700, Robert Walsh wrote: > > > Why do you think these are malloc bugs? These are locations in your > > > code where you called malloc to allocate memory but subsequently never > > > freed it. These are genuine memory leaks. What do you mean "can not > > > reproduce them"? > > > > Yeah, sorry for saying "can not reproduce them". What I mean to say > > is, I can not figure out how to track down the leak. Usually, I can do > > this very easily. For some reason, I can't do it in this case. > > > > Valgrind usually reports when the memory was leaked, right? Because the > > left hand side of the assignment is NULL when the malloc is done and > > assigns the value. How could this be a memory leak? > > Valgrind reports where (not when) the memory that was leaked was > allocated. So that malloc stack backtrace you see was an instance of > some memory that was allocated but never freed. The lvalue would only > factor into this if it already pointed to some allocated memory: > > 1: char *lv; > 2: lv = malloc(10); > 3: lv = malloc(10); > 4: free(lv); > > would show up as a memory leak on line 2. Nothing would show up for > line 3, which is where the leak actually happens. > > You can instrument your code to force Valgrind to do a leak check on the > fly, which might help you track down exactly where the leak is > happening. See the instructions for VALGRIND_DO_LEAK_CHECK in the user > guide. Well, I finally found the memory leak. Most of the time it's much easier, but this time it was difficult. Thanks for the help. Bob Rossi |