[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-devel
Subject:    Re: memory leak :(
From:       Alan DeKok <aland () striker ! ottawa ! on ! ca>
Date:       2000-03-27 21:41:17
[Download RAW message or body]

"Kiernan, Alex" <alexk@demon.net> wrote:
> This seems to be the behaviour thats there, and there aren't memory leaks
> AFAICS (but I've a patch to fix a core dump & a feature which allows the
> request id to be set for radclient which allowed me to test the the same id
> arriving):

  OK.  I've applied your patches.

  I've also fixed the "memory leak" problem on the server.  CVS log
is:


   new function: rad_clean_list().  This implements much of the
   functionality that used to be in rad_check_list().

   rad_check_list() now checks ONLY for duplicates of the current
   request.  This behaviour is the same as previously.

   rad_clean_list() now takes over the job of checking for cleanup_delay,
   max_request_time, doing pthread_join(), and deleting old requests.
   All of this functionality used to be in rad_check_list.

   In addition, rad_clean_list() now has checks so that it may be called
   for every request, but it only walks through the list AT MOST, once
   a second.  This saves walking through the request list 100 times/s
   for loaded servers.

   And this also makes it easy to call rad_clean_list() if the select()
   call fails with EINTR.  This will allow us to immediately clean up
   the list if a child exits, or if we got a SIGHUP.


  This isn't perfect, as any children will wait around longer until
they've been cleaned up, but it shouldn't be too much of a problem.
The child processes/threads will get cleaned up quickly, even on a
lightly loaded system.

  Hmm... I'm starting to think it would be cleaner to move the request
list handling code to a new file, 'requests.c'.  This would make later
threading additions easier, too.

  Alan DeKok.

[prev in list] [next in list] [prev in thread] [next in thread]