The problem he's encountered has nothing to do with the thread's
stack space: it means that one single method is trying to use more
than 32k of stack space, all by itself.
This limit has never changed, though the details of code generation
change often enough that a method which is very near the limit may
come out above or below the limit depending on the compiler version.
32k is a really enormous amount of stack space; any method which
hits this limit really ought to be broken down into more manageable
pieces.
In my particular case, the method was simply loading constants to
initialize a Blowfish encryption scheme into an array which was a
property external to the method (a property of a Blowfish class). The
array took 4 x 256 integers, which should be 4k bytes, right? I can
understand that the constants defined in the method would take up
stack space, but it would seem that there would be no other obvious
reason for the storage requirements to be multiplied by 8. However, I
guess that there was a coding change between 2005 and 2006 that meant
that much more information than before was also loaded on to the stack.
There is no logical reason to break this simple and straightforward
initialization method up into two parts, but I did anyway, and that
solves the problem. But my point is that it is possible for a
perfectly reasonable method to exceed this limit (and not for any
obvious reason, either).
Best wishes, Tom
-------------------------------------------------------------
This message has been scanned by Postini anti-virus software.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
