Fast session resumption segfault

[Phil Mayers]

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)