I've been doing some minor butchery to the code, scattered all over the place. It's a result of running "valgrind", with full leak checking enabled. I've found a number of places where memory was being leaked. They weren't serious, but they should be fixed. The code now leaks ~300 bytes on a normal startup to clean exit, where it doesn't receive packets. That's down from 100's of K before. This should make it easier to track down *real* memory leaks inside of the server. Plus, I've integrated the configuration file parser && free code. So all of the modules that previously laboriously free'd strings allocated by cf_section_parse() don't have to do that any more. That should make the code a little cleaner. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 12 Feb 2007 16:13, Alan DeKok wrote:
I've been doing some minor butchery to the code, scattered all over the place. It's a result of running "valgrind", with full leak checking enabled. I've found a number of places where memory was being leaked. They weren't serious, but they should be fixed.
The code now leaks ~300 bytes on a normal startup to clean exit, where it doesn't receive packets. That's down from 100's of K before.
This should make it easier to track down *real* memory leaks inside of the server.
Nice.
Plus, I've integrated the configuration file parser && free code. So all of the modules that previously laboriously free'd strings allocated by cf_section_parse() don't have to do that any more. That should make the code a little cleaner.
Ohhh.. Goody.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
This should make it easier to track down *real* memory leaks inside of the server.
Nice.
I just committed a few patches to libltdl in CVS head. Yes, we should try to be close to their code (and the version we have is old), but in the interest of cleanup. There are a lot of other complaints from valgrind about libltdl over-reading buffers, but that's not much of a problem.
Plus, I've integrated the configuration file parser && free code. So all of the modules that previously laboriously free'd strings allocated by cf_section_parse() don't have to do that any more. That should make the code a little cleaner.
Ohhh.. Goody..
Yeah, and added a few paircompare_unregister(), etc. It now leaks *zero* bytes at exit when using '-m'. This includes situations where it sends/receives packets. So memory leaks should be a whole lot easier to track down. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Yeah, and added a few paircompare_unregister(), etc.
It now leaks *zero* bytes at exit when using '-m'. This includes situations where it sends/receives packets. So memory leaks should be a whole lot easier to track down.
Alan DeKok.
This sounds too good to pass up. Sigh. Gotta rebase and rebuld off cvs head again now..... Thanks Alan. Dont know if its a leak or full symbols or anything but... root 5122 5122 0.0 8 1.2 116796 13340 ? Ssl Feb09 1:32 /usr/sbin/freeradius root 5122 7202 0.0 8 1.2 116796 13340 ? Ssl 06:36 0:10 /usr/sbin/freeradius root 5122 7203 0.0 8 1.2 116796 13340 ? Ssl 06:36 0:10 /usr/sbin/freeradius root 5122 7204 0.0 8 1.2 116796 13340 ? Ssl 06:36 0:09 /usr/sbin/freeradius root 5122 7205 0.0 8 1.2 116796 13340 ? Ssl 06:36 0:10 /usr/sbin/freeradius root 5122 7208 0.0 8 1.2 116796 13340 ? Ssl 06:36 0:10 /usr/sbin/freeradius root 5122 7209 0.0 8 1.2 116796 13340 ? Ssl 06:36 0:10 /usr/sbin/freeradius root 5122 7211 0.0 8 1.2 116796 13340 ? Ssl 06:36 0:10 /usr/sbin/freeradius Joe
Joe Maimon wrote:
This sounds too good to pass up. Sigh. Gotta rebase and rebuld off cvs head again now.....
branch_1_1 has the same fixes, IF you wait for all of the requests to be cleaned up. I haven't yet gotten around to having it clean up the request list on exit. Again: $ radiusd -m -Xd ./raddb Means that you can run the server, and once it's been idle for 5 seconds, hit ctrl-C. Anything you see using "valgrind --tool=memcheck" other than ltdl.c is a memory leak that needs to be fixed.
root 5122 5122 0.0 8 1.2 116796 13340 ? Ssl Feb09 1:32 /usr/sbin/freeradius
Maybe you have a busy server? Without more information, it's hard to tell. Most of the changes I just added are for proper cleanup at exit. So they don't affect the normal running of the server. They do, however, make it a lot easier to read the output. There's less noise, which means the real leaks are obvious. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Feb 12, 2007, at 10:06 AM, Alan DeKok wrote:
Most of the changes I just added are for proper cleanup at exit. So they don't affect the normal running of the server. They do, however, make it a lot easier to read the output. There's less noise, which means the real leaks are obvious.
That'll be a big help. I haven't gotten back to it (and it may be fixed by now through some other attrition), but I've been trying to track down a nasty leak in either the eap or eap-tls module for some time now. --Mike
participants (4)
-
Alan DeKok -
Joe Maimon -
Michael Griego -
Peter Nixon