On Sat, 2003-08-02 at 00:28, Clint Jeffery wrote:
> I believe a "fix" will now be relatively straightforward; thanks again
> Kazimir for packaging the problem up so nicely!
>
> The good news about all this is that for many years we have just been
> shrugging our shoulders and saying "C stack overflow, can't help it", about
> most reported Icon and Unicon virtual machine crashes. But from this
> exercise it appears that we can do something to alleviate this on many
> or most platforms.
>
> Like the BLKSIZE discussion earlier, one of the big issues is how to
> select an appropriate C stack size, based on the system memory, such
> that users don't need environment variables or flags to set it to a
> non-default value.
Thanks Clint! This is good news and the C stack overflow makes sense
(though I'm having trouble understanding why changing BLKSIZE affects
that overflow [unless the overflow was undetected by the hardware and
oozing into the heap, with the larger BLKSIZEs resulting in a larger
gap between the two...], I'll put that down to my lack of knowledge).
That was quick work - I'm impressed!
-Steve
--
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materietur marmota monax si marmota
monax materiam possit materiari?
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
