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@radtest ~]# addr2line -e /opt/fr3/sbin/radiusd 0x433531 /home/nsg/freeradius-server/src/main/process.c:472 [root@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?