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. --ado -----Original Message----- From: Ted Unangst [mailto:ted.unangst@gmail.com] Sent: Tuesday, November 23, 2010 10:08 To: Christos Zoulas Cc: tz@elsie.nci.nih.gov; tz@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@zoulas.com> wrote:
On Nov 22, 4:44pm, eggert@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 this list. We can just patch this in openbsd, it's not that big a deal, but wanted to pass the change upstream as well.