assert on listen.c:565
CVS 11/27 On older CVS versions I had this patch, which I am testing again as a solution. Server starts to log below after running fine for close to 12 hours...... Mon Nov 28 04:05:18 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 32 Mon Nov 28 04:05:18 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 35 Mon Nov 28 04:05:18 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 36 Mon Nov 28 04:05:19 2005 : Proxy: marking accounting server 90.90.90.15:1646 for realm jnet dead Mon Nov 28 04:05:21 2005 : Proxy: marking accounting server 90.90.90.15:1646 for realm jnet dead Mon Nov 28 04:05:22 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 37 Mon Nov 28 04:05:23 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 35 Mon Nov 28 04:05:23 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 33 Mon Nov 28 04:05:23 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 36 Mon Nov 28 04:05:23 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 34 Mon Nov 28 04:05:23 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 32 Mon Nov 28 04:05:24 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 37 Mon Nov 28 04:05:24 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 38 Mon Nov 28 04:05:24 2005 : Auth: Login incorrect: [CCCCCCC/cisco] (from client noc08rt08 port 805372387) Mon Nov 28 04:05:24 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 39 Mon Nov 28 04:05:25 2005 : Auth: Login OK: [ruth@CCCCCCC] (from client noc08rt08 port 805372387) Mon Nov 28 04:05:26 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 35 Mon Nov 28 04:05:26 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 36 Mon Nov 28 04:05:27 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 38 Mon Nov 28 04:05:27 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 37 Mon Nov 28 04:05:29 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 39 Mon Nov 28 04:05:32 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 38 Mon Nov 28 04:05:34 2005 : Proxy: No outstanding request was found for proxy reply from home server 90.90.90.15 port 1646 - ID 39 Mon Nov 28 04:05:59 2005 : Auth: Login incorrect: [XXXX/cisco] (from client noc08rt08 port 810287241) Mon Nov 28 04:06:05 2005 : Error: Assertion failed in listen.c, line 565 #! /bin/sh /usr/share/dpatch/dpatch-run ## 090-assert-listen-proxy.dpatch by <joe@nameserver3.ttec.com> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad freeradius-1.1.0~/src/main/listen.c freeradius-1.1.0/src/main/listen.c --- freeradius-1.1.0~/src/main/listen.c 2005-11-27 15:47:21.000000000 -0500 +++ freeradius-1.1.0/src/main/listen.c 2005-11-28 08:08:57.000000000 -0500 @@ -562,8 +562,10 @@ */ static int auth_socket_send(rad_listen_t *listener, REQUEST *request) { - rad_assert(request->listener == listener); - rad_assert(listener->send == auth_socket_send); + if (request->proxy_listener != listener) { + rad_assert(request->listener == listener); + rad_assert(listener->send == auth_socket_send); + } /* * Ensure that the reply is sane
Joe Maimon <jmaimon@ttec.com> wrote: ... The simple solution, I think, is to delete the assertion that "request->listener == listener". This fails after a HUP, when the listener is re-allocated. Hmm... this highlights a serious bug. The listener should NEVER be re-allocated, because it's being pointed to from live requests. Therefore, the code in listen.c shouldn't allocate a new listener, but should instead yank the old one from the old list. Alan DeKok.
Alan DeKok wrote:
Joe Maimon <jmaimon@ttec.com> wrote: ...
The simple solution, I think, is to delete the assertion that "request->listener == listener". This fails after a HUP, when the listener is re-allocated.
My issue happened well after any HUPS were sent.
Hmm... this highlights a serious bug. The listener should NEVER be re-allocated, because it's being pointed to from live requests.
Hours after a hup? Or should listeners contain a reference count?
Therefore, the code in listen.c shouldn't allocate a new listener, but should instead yank the old one from the old list.
Except if the listen configuration changes.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Joe Maimon <jmaimon@ttec.com> wrote:
Hours after a hup? Or should listeners contain a reference count?
Yes, hours. It's called "luck". Maybe a reference count would fix it, but that's a lot of overhead.
Therefore, the code in listen.c shouldn't allocate a new listener, but should instead yank the old one from the old list.
Except if the listen configuration changes.
Well, yes, but then the new one won't match an old one. Alan DeKok.
participants (2)
-
Alan DeKok -
Joe Maimon