Memory leak in dual_tls_receive
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.
I’ve pushed a fix. See commit #f3f13d18. It’s a one-line change to allocate the request with the correct parent context. Once that change is done, the request->reply should be cleaned up, too. Alan DeKok.
I’ve pushed a fix. See commit #f3f13d18. It’s a one-line change to allocate the request with the correct parent context. Once that change is done, the request->reply should be cleaned up, too.
Hi Alan, I'm assuming that this fix is in both the 3.0.x and master, right? If so, I'm still seeing the same behaviour that we reported to Sam (and that he investigated). :-/ I've been running 3.0.8 (head of 3.0.x) for 19 hours and memory usage grew from 0.7% (7348KB RSS) at 16:00 yesterday to 4.3% (44572KB RSS) around 9:40 this morning. I'll restart with 3.1.0 (head of master) and see what happens with that. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On Mar 4, 2015, at 4:42 AM, Stefan Paetow <Stefan.Paetow@JISC.AC.UK> wrote:
I’ve pushed a fix. See commit #f3f13d18. It’s a one-line change to allocate the request with the correct parent context. Once that change is done, the request->reply should be cleaned up, too.
I'm assuming that this fix is in both the 3.0.x and master, right? If so, I'm still seeing the same behaviour that we reported to Sam (and that he investigated). :-/
Yes, the fix is in both places.
I've been running 3.0.8 (head of 3.0.x) for 19 hours and memory usage grew from 0.7% (7348KB RSS) at 16:00 yesterday to 4.3% (44572KB RSS) around 9:40 this morning.
That’s not good. I’ll take a look at Sam’s other bug reports later today. The fix should be simple. Alan DeKok.
I've been running 3.0.8 (head of 3.0.x) for 19 hours and memory usage grew from 0.7% (7348KB RSS) at 16:00 yesterday to 4.3% (44572KB RSS) around 9:40 this morning.
That’s not good. I’ll take a look at Sam’s other bug reports later today. The fix should be simple.
Ok, My system is available to run this again if needed/required. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
participants (3)
-
Alan DeKok -
Sam Hartman -
Stefan Paetow