[EMAIL PROTECTED] (Rainer Clasen) wrote:
Even with the changes from the radiusd.c you sent me, this goto is still
triggered.
sigh I think it's the threading problems. The server still uses
a few functions which aren't thread-safe, and they should be made
thread safe.
e.g. gmtime(),.
While non-optimal, would a mutex lock around non threadsafe functions be a
viable workaround? It at least allowed a program I've written to function
safely ..
Penned by Alan DeKok on Mon, Feb 25, 2002 at 05:44:48PM -0500, we have:
| [EMAIL PROTECTED] (Rainer Clasen) wrote:
| Even with the
Todd T. Fries [EMAIL PROTECTED] wrote:
While non-optimal, would a mutex lock around non threadsafe functions be a
viable workaround? It at least allowed a program I've written to function
safely ..
That's about as much work as fixing the code to use the thread-safe
functions, instead of
Alan DeKok wrote:
Hmm... I would suggest going to src/main/radiusd.c, function
refresh_request(). Look for:
[...]
and add:
if (request-reply (request-reply-code != 0)) goto setup_timeout;
I've added this to the version already running with your fix from
yesturday.
Now I'm
[EMAIL PROTECTED] (Rainer Clasen) wrote:
I've taken the changes from CVS and applied them to my patched version
(only logging enhancements). proxy.c:1.52-1.53, radiusd.c:1.238-1.239.
I got the following backtrace:
...
(gdb) p *request
$1 = {magic = 16909060, packet = 0x0, proxy = 0x0,
Hallo erstmal!
Rainer Clasen schrieb:
Alan DeKok wrote:
Hmm... I would suggest going to src/main/radiusd.c, function
refresh_request(). Look for:
[...]
and add:
if (request-reply (request-reply-code != 0)) goto setup_timeout;
I've added this to the version already
Hallo erstmal!
Rainer Clasen schrieb:
Rainer Clasen schrieb:
Alan DeKok wrote:
Hmm... I would suggest going to src/main/radiusd.c, function
refresh_request(). Look for:
[...]
and add:
if (request-reply (request-reply-code != 0)) goto setup_timeout;
I've added
[EMAIL PROTECTED] (Rainer Clasen) wrote:
Mitchell, Michael wrote:
I'm currently testing freeradius-snapshot-20020114 (configured as a proxy
only) on Solaris 8 and running into a problem.
I'm seeing similar crashes with my patched 2002-02-11 version on Solaris
7.
Hmm... I'm starting to
Mitchell, Michael wrote:
I'm currently testing freeradius-snapshot-20020114 (configured as a proxy
only) on Solaris 8 and running into a problem.
I'm seeing similar crashes with my patched 2002-02-11 version on Solaris
7.
#0 0x19510 in proxy_send (request=0x1b13250) at proxy.c:398
Rainer Clasen wrote:
in both cases the only server for a realm was marked dead immediately
before the crash.
I forgot to mention: This server has the secret, which is in
request-proxy_secret when the daemon dies. So it seems to be a packet
related to the same server which was marked dead.
[EMAIL PROTECTED] (Rainer Clasen) wrote:
in both cases the only server for a realm was marked dead immediately
before the crash.
On further examination, the code in rad_respond() does NOT check for
errors returned from proxy_send(). So if the request is marked to be
proxied, and the realm
Mitchell, Michael [EMAIL PROTECTED] wrote:
Setting cleanup_delay to 0 seems to have helped to alleviate the
problem, but it does not prevent it. The server tends to run longer before
crashing - we're into the minutes now rather than seconds - but the problem
is definitely still there.
PROTECTED]]
Sent: Wednesday, 16 January 2002 11:15
To: [EMAIL PROTECTED]
Subject: Re: FreeRADIUS crashing on Solaris 8
Hi,
In radiusd.conf, try setting 'cleanup_delay' to 0 or even
-1. It seems to
be related to some different segfaults I've been seeing.
Mine have to do
with CHAP
13 matches
Mail list logo
