From owner-freebsd-bugs Fri Jun 11 21:10: 3 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 68B5514E9A for ; Fri, 11 Jun 1999 21:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA40098; Fri, 11 Jun 1999 21:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 11 Jun 1999 21:10:01 -0700 (PDT) Message-Id: <199906120410.VAA40098@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "David Schwartz" Subject: Re: kern/12141: libc_r passes negative tv_usec values to setitimer -- crash Reply-To: "David Schwartz" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/12141; it has been noted by GNATS. From: "David Schwartz" To: , "David Schwartz" Cc: Subject: Re: kern/12141: libc_r passes negative tv_usec values to setitimer -- crash Date: Fri, 11 Jun 1999 21:04:53 -0700 Wow, it was an overflow in my code causing me to call pthread_cond_timewait with an out-of-range number of nanoseconds. One billion is awfully close to the maximum an unsigned int/long can hold, so overflows are easy. So the problem really is that pthread_cond_timedwait doesn't return an EINVAL when the input timespec is out of range. Instead it lets the scheduler fault later. The fix is either to document this unusual behavior or put sanity checks in pthread_cond_timedwait. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message