----- Original Message ---- > From: Jesse Becker <[EMAIL PROTECTED]> > To: Martin Knoblauch <[EMAIL PROTECTED]> > Cc: Ganglia Developers <[email protected]> > Sent: Wednesday, February 20, 2008 4:01:26 PM > Subject: Re: [Ganglia-developers] Memory leak in gmond > > On Feb 19, 2008 7:39 PM, Martin Knoblauch wrote: > > ----- Original Message ---- > > > From: Jesse Becker > > > To: Ganglia Developers > > > Sent: Tuesday, February 19, 2008 11:25:54 PM > > > Subject: Re: [Ganglia-developers] Memory leak in gmond > > > > > > I'm not sure if this is right--I've only take a really quick check in > > > libmetrics/linux/metrics.c, and my C-fu is rusty. > > > > > > It looks like strndup() is called in linux/metrics.c:hash_lookup > > > (about line 131) to dupliate an interface name, which is included in > > > the stats structure as stats->name. The net_dev_stats function will > > > return this struct. > > > > > > The function is called in a number of places pkts_in_func, > > > pkts_out_func, bytes_out_func and bytes_in_func. The variable "*ns" > > > is assigned the output of hash_lookup (e.g. the struct). Since the > > > 'name' element is malloc()ed, but not explictly freed, it will not go > > > away when *ns goes out of scope. This is the leak, isn't it? All > > > four of these functions are very similar, and need to be fixed if this > > > is the case. > > > > > > Or did I miss something obvious? :) > > > > > > > Lines 137, 148 and 159 ? :-) > > I saw those. :-P I meant after the struct has been returned, outside > the function, the memory is never freed. Inside that function, it's > okay. >
We actually had a memory leak in that area. The four networking functions would alllocate and then leak the device-names. But that has been fixed in both trunk and 3.0.X about 10 days ago. > > The memory allocated in line 151 is never freed, indeed. But it is only > > allocated once per interface and stays alive for the entire lifetime of the > > gmond process. So, it is not leaked. > > Ah, that makes more sense, especially if those variables exist for the > lifetime of the program. > Yup. It is really important to know that the lifetime of those structures. We actually might have a problem in the case when hot-unplugging network cards. But I guess that the resulting "leak" might be tolerable :-) > So, I've just run gmond under valgrind and duma (a fork of the old > Electric Fence memory debugger), and I can't seem to reproduce the > problem now. Neither one of them is showing any obvious leaks, at > least not in the 15 minute tests I've run. The test system(s) are > CentOS4.6 boxes. > These things happen. Cheers Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
