<div dir="ltr"><div>we&#39;re still having trouble with tzcode using unreasonable amounts of stack. things were somewhat ameliorated by defining the oddly-named ALL_STATE. that causes tzcode to allocate tzload&#39;s &#39;u_t&#39; on the heap instead of the stack. that takes about 40KiB off tzload&#39;s stack requirements, which was by far the biggest offender.</div>

<div><br></div><div>unfortunately, later on in tzload there&#39;s a &#39;struct state&#39; allocated on the stack. on LP64, that&#39;s about 18KiB, which -- even if it&#39;s not 40KiB -- is still unreasonable in one frame! LP32 is about 9KiB less, because our LP32 time_t was only 32-bit, so we&#39;ve been getting away with it there --- threads with 16KiB stacks could safely call tzcode functions. but this isn&#39;t true for LP64.</div>

<div><br></div><div>(note that these rough figures are with TZ_MAX_TIMES at 1200 --- we haven&#39;t yet bumped that to the 2000 it seems to be at head.)</div><div><br></div><div>we&#39;ll fix this in Android (the first hunk in <a href="https://android-review.googlesource.com/#/c/94653/">https://android-review.googlesource.com/#/c/94653/</a>) but it would be nice if this were fixed upstream too so we don&#39;t have to diverge more than we already have.</div>

<div><br></div><div> --elliott</div><div><br></div></div>