On 23 Jun 2014, at 21:41, Alan DeKok <aland@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@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2