Memory leak in dual_tls_receive

[Sam Hartman]

Hi.

One of the Moonshot sites has been having trouble with a memory leak
that I've been trying to track down.  I've just reproduced this with
3.0.7 with a minor patch to get the trust router code compiling after a
change in the home server structure between 3.0.6 and 3.0.7.  I'll send
along that patch shortly.

I've set up Freeradius in valgrind and am getting consistent behavior
with 3.0.4 and 3.0.7 (and Stefan sees a leak with 3.0.6).

what I see is that sometimes the following hunks in dual_tls_receive
leak:

        if (!sock->request) {
                        sock->request = request = request_alloc(NULL);
/* possibly leaked 379 times out of 6,951 requests*/
                        
                /*
                                 *      Not sure if we should do this on
                every packet...
                                 */
                                                 request->reply =
                rad_alloc(request, false);
/* definitely  leaked 258 times ; possibly leaked 379out of 6,951 requests*/

In valgrind, a possible leak means that  there is a live pointer to
something within the structure, but not the beginning.
If you're playing weird pointer games that might not be a leak.
However, it seems fairly clear to me that from the indicated code a
possible leak in valgrind's vocabulary is a real leak.


My client will use a new TLS client socket per EAP authentication, but
probably tends to keep the socket open for each request in an
authentication.  I think I'm seeing 6-7 messages per authentication.
So, I don't think it's just that it's leaking once per socket open,
although that might be it.



I don't understand the memory management for the structures involved
well enough to evaluate correctness.
Where should those requests be being freed?
what should I look into?

Also, I am waiting for all the client sockets to close and be cleaned up
before taking the valgrind dump.