Alan,
I tested the 20020203 snapshot with the _r() changes.
I ran then server without the -s option (radiusd -p 1812 ) and it cored
dump:
#0 pairmove (to=0x38, from=0x42964990) at valuepair.c:186
#1 0x08051614 in radius_exec_program (cmd=0x80fde28
"/usr/local/freeradius/auth/bin/autenticadbm %u %f %w",
request=0x8111188, exec_wait=1, user_msg=0x42966e78) at exec.c:305
#2 0x0805259c in rad_authenticate (request=0x8111188) at auth.c:832
#3 0x0804dcd0 in rad_respond (request=0x8111188, fun=0x8051d50
<rad_authenticate>) at radiusd.c:1472
#4 0x08056e04 in request_handler_thread (arg=0x80e4b08) at threads.c:169
#5 0x40061b9c in pthread_start_thread (arg=0x42967be0) at manager.c:274
#6 0x40061c7f in pthread_start_thread_event (arg=0x42967be0) at
manager.c:298
If I run it with -s (radiusd -s -p 1812) works fine.
[]s
btw.. did you have (extra) time to revise the rlm_radutmp patch that I sent
?
------------------------------------------------------------
Marcelo Ferreira
Canbras TVA Cabo Ltda
Canbras Acesso - STA
Phone: +5511-4993-8728
------------------------------------------------------------
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 02, 2002 2:02 PM
Subject: Re: Thread issue - Possible fix
> "Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote:
> > Well, you should be able to link against thread-safe variants of
> > those functions, right? I mean, strtok() is obviously not
> > thread safe, but localtime() should be.
>
> Nope. Log into a *BSD box. The thread-safe variant of localtime()
> is localtime_r(). Localtime returns a pointer to static data, which
> can be over-written in subsequent calls.
>
> I've *never* understood why people designed functions which returned
> pointers to static data. They don't even scale on *one* process, much
> less multi-threaded.
>
> e.g. Try to keep two different pointers to data returned by two
> subsequent calls to localtime(), for two different dates. You can't.
> You get the same pointer both times. So the second call over-writes
> the data from the first call.
>
> So the only sane way to use that function even in a process with one
> thread of execution, is to copy the results to another buffer. But if
> that's true, why the heck didn't localtime just take a pointer to the
> place to store the returned data?
>
> But I digress...
>
> > It's probably just a matter of linking against the right library.
> > libc_r instead of libc, most likely.
>
> libc_r usually has the foo_r() functions. libc() doesn't.
>
> libc_r usually *also* has the unsafe foo() functions, so people who
> want to shoot themselves in the foot can do so.
>
> > I think Linux turns on thread-safety if you define -DREENTRANT
> > and link with -pthreads. Other systems might need other
> > magic incantations. Like FreeBSD, and probably Solaris.
>
> glibc does *insane* things to be thread-safe while returning
> pointers to static data. That's why Linux doesn't have the foo_r()
> functions.
>
> It's also why glibc is so much larger and more complicated than the
> *BSD C libraries. They're trying to be smart & cute, instead of
> writing simple, clean, code.
>
> > Don't just substitute all library functions for their _r equivalents,
> > just find out how to link against the thread-safe libc variant.
>
> The server has been linking that way for a while, and it isn't good
> enough. People other than the glibc hackers run away screaming when
> asked to make thread-safe versions of localtime(), etc.
>
> The simplest thing to do is to *always* use the localtime_r()
> functions, and to have a trivial wrapper around localtime() using
> 'memcpy' to get the same effect. I've made that change in the server
> for ctime_r() and for localtime_r(). If it *creates* problems, I'd
> love to know.
>
> IMHO, *all* of the functions returning pointers to static data
> should just go away. They're badly designed.
>
> Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
