stack overflows
stack overflows
- Subject: stack overflows
- From: has <email@hidden>
- Date: Fri, 9 Nov 2001 00:25:51 +0000
Hi,
I'm trying to get a better idea of when and how stack overflows occur, so i
can judge just how far to push AS before it gets unsafe. For example, I'm
writing a TID-based find-and-replace (no laughter in the back, please; this
one's just a little more advanced than usual;) and the last part of the
process requires the string to be broken down on every second character. So
whilst you might get by with a basic F&R arrangement for normal use (since
the chances of finding the same character more than a couple thousand times
is probably very low, even in quite large strings), this thing is
guaranteed to barf on anything more than a few KB.
So I wrote the following test script to see just how many items could be
broken down to list at once, and it seemed to be pretty constant at 4000.
But... I realise this may or may not mean anything in practice; I don't
know enough about AS's guts that I can tell.
======================================================================
set x to {}
set s to "1234567890"
repeat 10 times
set end of x to s
end repeat
set s to x as string --100 characters
repeat
set end of x to s
try
set y to every item of (x as string)
on error
beep
return (count (x as string))
end try
end repeat
end
--> ralphs when trying to convert a >4000 item string to a >4000 item list
======================================================================
So I guess the question is: how do you know how much space you've got in
the stack? Would I be right in thinking that if you're already deep down in
recursive routines when you run this routine, it's going to overflow much
sooner? (Since presumably the stack is already partly filled by then.) What
exactly goes into the stack: can it be big things or little things,
depending on what it is being done, or is everything that goes on a nice
predictable size? Is stack size (and thus the amount of stuff it can take
before overflowing) dependent on the amount of free memory your
editor/applet has, or something else entirely? Does anyone know what the
winning numbers for next week's lottery will be?
Hell, can you even try to second-guess this stuff in the first place -or is
it simply better to make sure you write good error handlers? For example, I
can modify my F&R to get the text items a few at a time; I already have a
batching handler written for another section that I could adapt for the
purpose - catch any overflows and reprocess the problem data in a safer -
though slower - manner. Of course, all this extra code is going to mean the
whole thing runs slower in the end, which isn't so good either. Kinda
between devil and deep blue sea, I guess.
Any advice? Thanks.
has