FW: FW: stack overflow in tzload
Olson, Arthur David (NIH/NCI) [E]
olsona at dc37a.nci.nih.gov
Tue Nov 23 15:26:28 UTC 2010
I'm forwarding this message from Ted Unangst, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
From: Ted Unangst [mailto:ted.unangst at gmail.com]
Sent: Tuesday, November 23, 2010 10:08
To: Christos Zoulas
Cc: tz at elsie.nci.nih.gov; tz at lecserver.nci.nih.gov; Olson, Arthur David (NIH/NCI) [E]
Subject: Re: FW: stack overflow in tzload
On Mon, Nov 22, 2010 at 11:28 PM, Christos Zoulas <christos at zoulas.com> wrote:
> On Nov 22, 4:44pm, eggert at cs.ucla.edu (Paul Eggert) wrote:
> -- Subject: Re: FW: stack overflow in tzload
> | Surely this sort of change should be put in only conditionally.
> | On most machines, the change would will slow performance down due to the
> | malloc overhead and would add one more point of failure.
> | Only on machines with tiny stacks is the change a win.
> Sure, but these days the cost of malloc is really small, and having more
> ifdefs in the code just cause more maintenance. So we either adopt the
> change, or we just tell Ted that if you run with < 256K of stack you
> can expect lots of things to break - not just that - so give yourself more
All fair points, but it happens that this is the thing that broke.
Smallish stacks are not uncommon if you expect to be creating many
threads (the app in question is a of web server not of my own design,
I'm not even sure what stack size it expects).
The real wrinkle is that the tz code is part of the system library, I
expect it to just work. If somebody had asked last week "How much
stack does calling gmtime() require?", I suspect most people's answers
would fall short of the mark, apart from maybe a very few people on
We can just patch this in openbsd, it's not that big a deal, but
wanted to pass the change upstream as well.
More information about the tz