Error: ASSERT FAILED threads.c
aland at deployingradius.com
Mon Jul 26 13:35:16 CEST 2010
Meyers, Dan wrote:
> Ran fine for a week or so, but in the last few days we've had it crash
> twice, both times with the same message. The logs initially fill with
> messages of the sort:
> "Sat Jul 24 01:05:08 2010 : Error: WARNING: Unresponsive child for
> request 128145, in module perl component accounting"
> We'll end up with 32 of the former type of error message (we're
> currently running with 32 threads configured in the thread_pool in
> radius.conf), interspersed with the latter, then a stack of the latter
> type of error (Always for the same set of requests, i.e. one of the ones
> we got an initial error for, but we'll get the second error multiple
> times for a given request). Then eventually we get
> "Sat Jul 24 01:05:27 2010 : Error: ASSERT FAILED threads.c:
> (*request)->magic == REQUEST_MAGIC"
That looks like a bug which will be fixed in 2.1.10. See
http://git.freeradius.org, branch v2.1.x. Download that and install it.
It should fix the problem.
If so, please say so.
> All our accounting module does in perl is convert the incoming radius
> hash to yaml and then attempt to write it to a database with a
> timestamp. I am strongly suspecting that the initial problem is to do
> with threading in combination with the DBD::MySQL module in perl or the
> MySQL client rather than FreeRADIUS, despite our testing seeming to show
> it was OK. But I do not think that final ASSERT FAILED error should be
> being generated as a result of the former issue. I am trying to
> understand what is going on. Is FreeRADIUS attempting to kill the
> deadlocked threads and being unable to do so?
It's a corner case that wasn't being handled properly.
More information about the Freeradius-Users