Error: ASSERT FAILED threads.c[406]

Alan DeKok 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"

  Oops.

> 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[406]:
> (*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.

  Alan DeKok.



More information about the Freeradius-Users mailing list