assert on listen.c:565

classic Classic list List threaded Threaded
4 messages Options
| Threaded
Open this post in threaded view
|

assert on listen.c:565

Joe Maimon
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  <[hidden email]>
##
## 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: assert on listen.c:565

Alan DeKok
Joe Maimon <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: assert on listen.c:565

Joe Maimon


Alan DeKok wrote:

> Joe Maimon <[hidden email]> 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
>
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: assert on listen.c:565

Alan DeKok
Joe Maimon <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html