talloc & threads in rlm_eap

[Phil Mayers]

On 23/06/2014 21:41, Alan DeKok wrote:

>> /tmp/threadlog-26294-26326-src/main/process.c:1369
>
>    Hmm... OK.
>
>> /opt/fr3/sbin/radiusd[0x435799]
>> /opt/fr3/sbin/radiusd[0x433531]
>
>    That's unhelpful.

Yeah, annoying that. I can run addr2line on those so I've no idea why 
backtrace() can't resolve them, but can resolve shared libs. Sigh.

Anyway, they resolve to:

[root at radtest ~]# addr2line -e /opt/fr3/sbin/radiusd 0x433531
/home/nsg/freeradius-server/src/main/process.c:472

[root at radtest ~]# addr2line -e /opt/fr3/sbin/radiusd 0x435799
/home/nsg/freeradius-server/src/main/process.c:1450

>    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...

In that particular case it was an access-after-free; I think maybe 
(ironically) the request_running() VERIFY_REQUEST() call is walking the 
vps at the same time the child thread is running through them?

Are we (well, I) actually seeing access-after-free being triggered by 
the VERIFY_* stuff? Which wouldn't happen in a release build?

That said I'm not seeing the locking or lock-free primitives which would 
ensure a request isn't accessed from main & worker thread; what's to 
stop a child thread updating request->child_state at the same time 
request_process_timer reading it?