On Fri, Nov 15, 2002 at 10:02:22AM +0100, Zoran Vasiljevic wrote:
> On Friday 15 November 2002 08:09, you wrote:
> > Turns out, *ALL* the Array Bounds Write, Free Memory Write and Read,
> > and other nasty Purify errors (aka, not just UMR) are from the "tzcpy"
> > function, which is called ultimately from localtime_u, localtime_r,
> > mktime, or strftime.
> You should not be using thread unsafe functions. Period.
> I know it does not help much in your case, but this is the bottom line.
> But, in this case, you should try modifying the thread/reentrant.c
> and lock the same mutex for localtime_r() in ns_localtime().
Well, I thought this might be of some interest. In 3.3+ad13, I went
into "thread/reentrant.c" and had ns_localtime and almost all the
other functions there lock a single global mutex. Then when making
any call to my closed-source vendor library, I also locked that same
mutex. So now I know ALL use of the reentrant.c functions and my
vendor library are completely serialized.
Guess what? That didn't fix anything. But then I tried something
different. In "nsd/log.c" and "nslog/nslog.c", I changed the
appropriate functions to NOT call Ns_LogTime_LogTime2 when writing
timestamps to the server or access log. Instead, it just writes the
unix epoch time. E.g.:
Ns_ConfigGetBool("ns/parameters", "log_local_time_p", &log_local_time_p);
if (log_local_time_p == NS_TRUE) {
Ns_LogTime(buf);
} else {
/*
* Instead of the nice formatted time string, simply spit out
* the unix epoch time. On Solaris, this seems to fix issues
* with non-thread-safe vendor libraries which call
* localtime() rather than localtime_r().
* [EMAIL PROTECTED], 2002/11/21 02:27 EST
*/
sprintf(buf, "[%ld]", (long) time(NULL));
}
And that WORKED! My thread-safety problems seem to have gone away.
(In reality, they're probably still there, but they're at least orders
of magnitude less bothersome.)
Thing is, Ns_LogTime2 calls ns_localtime, but I'd already tried protecting
ns_localtime with a global mutex above, and that didn't seem to work.
And other than ns_localtime, there just isn't anything in Ns_LogTime2
that looks like a potential issue.
So, by simply replacing the pretty timestamp in the logs with an ugly
unix epoch integer, I've band-aided my thread safety problems by
simply enormously reducing the number of times AOLserver calls
localtime_r(). But why was that necessary? Why didn't the mutex
locking approach work?
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com
