On 18/10/11 15:16, Phil Mayers wrote:
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:
Ok, valgrind seems to be catching lots of: Invalid read of size 4 at 0x4C18E5B: vp_prints (print.c:493) by 0x4C18F43: vp_print (print.c:525) by 0x4259EB: debug_pair_list (valuepair.c:820) by 0x4367FE: tls_success (tls.c:2068) by 0x688C974: eaptls_success (eap_tls.c:118) by 0x66854D9: eaptype_call (eap.c:189) by 0x6685E9D: eaptype_select (eap.c:424) by 0x66847E3: eap_authenticate (rlm_eap.c:327) by 0x41F6DC: modcall (modcall.c:298) by 0x41C6E4: indexed_modcall (modules.c:788) by 0x40BE54: rad_authenticate (auth.c:381) by 0x42BFA2: request_running (process.c:1137) Address 0x6f338c0 is 32 bytes inside a block of size 320 free'd at 0x4A05D21: free (vg_replace_malloc.c:325) by 0x4C21E1E: pairfree (valuepair.c:224) by 0x4387F8: session_close (tls.c:436) by 0x4388A5: session_free (tls.c:475) by 0x6686836: eap_handler_free (mem.c:167) by 0x66849CD: eap_authenticate (rlm_eap.c:455) by 0x41F6DC: modcall (modcall.c:298) by 0x41C6E4: indexed_modcall (modules.c:788) by 0x40BE54: rad_authenticate (auth.c:381) by 0x42BFA2: request_running (process.c:1137) by 0x429E9A: request_queue_or_run (process.c:786) by 0x42BDAF: request_insert (process.c:1387) ...for me. I'm not very familiar with valgrind, but from what I can see, the 1st call stack is reading memory (the cached VALUE_PAIR* stuff I guess) that was freed at the location given in the 2nd call stack. Any suggestions for more magical incantations? (I haven't had much time today - our so-called NREN burnt 2 hours of my time moving patch leads from one port on a core router to another)