I had problems starting at the exact same time but on Solaris, where
they manifested as a EINVAL return from pthread_cond_tomedwait. After a
day of tracing the problem with debug builds and working with my
sysadmin to track what changed (of course, nothing had) I cam to the
same 1 billion second issue.
Which coincidentally is the expiry time (MaxOpen and MaxIdle) set on my
database connections.
My system is ACS-derived, so I wouldn't be surprised if these database
settings are common in other ACS-derived systems.
The only bug is that Ns_CondTimedWait doesn't do any wraparound on the
time parameter. All the same, I've been enjoying telling people that I
hit my first y2038 bug.
-J
Bas Scheffers wrote:
On 17 May 2006, at 21:34, Dossy Shiobara wrote:
Dave Siktberg seems to have narrowed it down to 2006-05-12 21:25.
In what timezone? It sound like that could equate to "Sat May 13
02:27:28 BST 2006", or 1147483648 seconds since epoch, which makes it
*exactly* 1,000,000,000 seconds until expiry of 32 bit time.
Coincidence? Seems too strange as to a computer that is not a nice
round number.
I wonder what Dan Brown would have to say about it! :)
Bas.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
