ALL_STATE not "all" enough
we'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's 'u_t' on the heap instead of the stack. that takes about 40KiB off tzload's stack requirements, which was by far the biggest offender. unfortunately, later on in tzload there's a 'struct state' allocated on the stack. on LP64, that's about 18KiB, which -- even if it'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've been getting away with it there --- threads with 16KiB stacks could safely call tzcode functions. but this isn't true for LP64. (note that these rough figures are with TZ_MAX_TIMES at 1200 --- we haven't yet bumped that to the 2000 it seems to be at head.) we'll fix this in Android (the first hunk in https://android-review.googlesource.com/#/c/94653/) but it would be nice if this were fixed upstream too so we don't have to diverge more than we already have. --elliott
enh wrote:
we'll fix this in Android (the first hunk in https://android-review.googlesource.com/#/c/94653/) but it would be nice if this were fixed upstream too so we don't have to diverge more than we already have.
Thanks for mentioning this. I installed the attached patch into the experimental repository on github. This should fix the problem you mentioned, along with a couple of other problems of the same ilk. This patch tries to things a bit so more-efficiently than what Android does, by calling malloc at most once per function. This patch assumes the buffer-overrun patch that I recently posted to the list.
thanks. i've switched Android over to your more complete fix. On Sat, Jun 14, 2014 at 11:45 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
enh wrote:
we'll fix this in Android (the first hunk in https://android-review.googlesource.com/#/c/94653/) but it would be nice if this were fixed upstream too so we don't have to diverge more than we already have.
Thanks for mentioning this. I installed the attached patch into the experimental repository on github. This should fix the problem you mentioned, along with a couple of other problems of the same ilk. This patch tries to things a bit so more-efficiently than what Android does, by calling malloc at most once per function.
This patch assumes the buffer-overrun patch that I recently posted to the list.
did the NSA fix this in their secured "droid" port? Todd On 6/18/2014 8:00 PM, enh wrote:
thanks. i've switched Android over to your more complete fix.
On Sat, Jun 14, 2014 at 11:45 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
enh wrote:
we'll fix this in Android (the first hunk in https://android-review.googlesource.com/#/c/94653/) but it would be nice if this were fixed upstream too so we don't have to diverge more than we already have.
Thanks for mentioning this. I installed the attached patch into the experimental repository on github. This should fix the problem you mentioned, along with a couple of other problems of the same ilk. This patch tries to things a bit so more-efficiently than what Android does, by calling malloc at most once per function.
This patch assumes the buffer-overrun patch that I recently posted to the list.
participants (3)
-
enh -
Paul Eggert -
todd