crash at [event.c:969] Failed to insert event
Hi, when I was playing with attrs.pre-proxy, at first I only added EAP-Message to the list, but not State. In the result, when an answre froma proxy came back, the above error message occured and the server exited (with -X). Version is 2.0.3. Full debug of the packet in question: Going to the next request Waking up in 0.3 seconds. Rejecting request 2 due to lack of any response from home server 158.64.1.220 port 1812 There was no response configured: rejecting request 2 Found Post-Auth-Type Reject +- entering group REJECT expand: /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/reply-detail -> /var/log/radius/radacct/20080408/eduroam-lu-service/reply-detail rlm_detail: /var/log/radius/radacct/%Y%m%d/%{RESTENA-Service-Type}-service/reply-detail expands to /var/log/radius/radacct/20080408/eduroam-lu-service/reply-detail expand: %t -> Tue Apr 8 11:11:18 2008 ++[reply_log] returns ok Finished request 2. [event.c:969] Failed to insert event I could reproduce this several times by proxying EAP and filtering State. It's okay if stuff doesn't work in that case, but crashing is not so good. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
when I was playing with attrs.pre-proxy, at first I only added EAP-Message to the list, but not State. In the result, when an answre froma proxy came back, the above error message occured and the server exited (with -X). Version is 2.0.3. Full debug of the packet in question: ... Rejecting request 2 due to lack of any response from home server 158.64.1.220 port 1812
That seems to be the common cause of this issue.
[event.c:969] Failed to insert event
<sigh>
I could reproduce this several times by proxying EAP and filtering State. It's okay if stuff doesn't work in that case, but crashing is not so good.
Yes. The crash is because a catastrophic failure happened, and it's likely better to die than to do the wrong thing. In any case... I've committed a work-around to CVS. I have *no* idea why it's happening, though. The code in question does: ...PROXIED: assert(request->next_callback != NULL); callback = request->next_callback; assert(callback != NULL); And the second assertion triggers. This isn't *exactly* what the code does, but is pretty close. As a result, I'm at a complete loss for why the *first* assertion doesn't trigger, but the *second* one does. Alan DeKok.
participants (2)
-
Alan DeKok -
Stefan Winter