Date: Sun, 24 Mar 2013 03:40:33 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r248672 - head/lib/libc/stdtime Message-ID: <40FB115A-AE6E-4BB4-AE47-50C1491F3CE2@FreeBSD.org> In-Reply-To: <201303240135.r2O1Zb95065964@svn.freebsd.org> References: <201303240135.r2O1Zb95065964@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 24, 2013, at 02:35, Dimitry Andric <dim@FreeBSD.org> wrote: > Author: dim > Date: Sun Mar 24 01:35:37 2013 > New Revision: 248672 > URL: http://svnweb.freebsd.org/changeset/base/248672 > > Log: > Compile contrib/tzcode/stdtime/localtime.c with -fwrapv, since it relies > on signed integer overflow wrapping. Otherwise mktime(3) and timegm(3) > can hang, in case the timestamp passed in struct tm is not representable > in a time_t. Specifically, any timestamp after 2038-01-19 03:14:07, in > combination with a 32-bit time_t. I first noticed this when Squid on a i386 machine started to hang every now and then, and started consuming 100% CPU in such cases. After rebuilding Squid with debug info, I found it hung in timegm(3), because some web servers apparently like to pass Last-Modified dates of "Fri, 31 Dec 9999 23:59:59 GMT", most likely to prevent caching. Note this is not an issue on amd64, since time_t is 64-bit there, so even a struct tm with tm_year=INT_MAX would work with mktime(3) and timegm().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40FB115A-AE6E-4BB4-AE47-50C1491F3CE2>