talloc & threads in rlm_eap

[Arran Cudbard-Bell]

On 23 Jun 2014, at 21:41, Alan DeKok <aland at deployingradius.com> wrote:

> Phil Mayers wrote:
>> 2. Subsequent freeing in the same thread:
>> 
>> /tmp/threadlog-26294-26326:freeing 0x7f0308000b90
>> /tmp/threadlog-26294-26326-libfreeradius-radius.so(+0x267c3)[0x7f03329517c3]
>> 
>> /tmp/threadlog-26294-26326-libtalloc.so.2[0x36ad4025a4]
>> /tmp/threadlog-26294-26326-libfreeradius-radius.so(pairfree+0x63)[0x7f0332951ad4]
>> 
>> /tmp/threadlog-26294-26326-src/main/process.c:1369
> 
>  Hmm... OK.
> 
>> /opt/fr3/sbin/radiusd[0x435799]
>> /opt/fr3/sbin/radiusd[0x433531]
> 
>  That's unhelpful.
> 
>> Given that "pairfree(&request->packet->vps)" in step #2 should null out
>> the pointer, I can only assume what we're seeing here is a request being
>> freed in the main thread at the same time as being freed in a child
>> thread? Something inside the timeout machinery?
> 
>  Maybe.  The main thread should NOT free anything associated with the
> REQUEST if the child thread is still running.  There are a number of
> checks for that...

Alan found potential race condition in the VERIFY_REQUEST macro when used in process.c

It might just have been that hitting the lists before the HEAD pointer had been set
to NULL.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140623/073b9a16/attachment.pgp>