talloc & threads in rlm_eap
p.mayers at imperial.ac.uk
Mon Jun 23 23:17:22 CEST 2014
On 23/06/2014 21:41, Alan DeKok wrote:
> Hmm... OK.
> 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
[root at radtest ~]# addr2line -e /opt/fr3/sbin/radiusd 0x435799
> 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?
More information about the Freeradius-Devel