On 17/10/11 21:03, Alan DeKok wrote:
Phil Mayers wrote:
More info - todays HEAD dies with:
(14) peap : Success (14) peap : Adding cached attributes to the reply: 8:��9<INVALID-TOKEN> <INVALID-TOKEN> (14) eap : Freeing handler *** glibc detected *** /usr/local/sbin/radiusd: double free or
Hmm... my quick checks a while ago showed that the same pointer was being passed into the cache as was coming out. So the corrupt data above really seems to indicate that the memory was free'd and re-used.
The sad thing is that I run it under "valgrind", and all I get is the SEGV. I don't see a double free. :(
The double free seems to be timing-related; for example, just now it did this: (14) peap : Adding cached attributes to the reply: 8>��9 <INVALID-TOKEN> "" (14) eap : Freeing handler (14) [eap] = ok <snip> (14) [detail] = ok Sending Access-Accept of id 14 to 155.198.51.229 port 42514 MS-MPPE-Recv-Key = 0x6... MS-MPPE-Send-Key = 0x3... EAP-Message = 0x03030004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "@ic.ac.uk" *** glibc detected *** /usr/local/sbin/radiusd: double free or corruption (!prev): 0x0000000016c80c70 *** Segmentation fault i.e. it managed to send the Access-Accept for the resumed session before the accident! Weirder and weirder. I am looking into it now.