[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]huge structs with ilrun , problems
From: |
Rhys Weatherley |
Subject: |
Re: [DotGNU]huge structs with ilrun , problems |
Date: |
Wed, 12 Feb 2003 07:29:52 +1000 |
User-agent: |
KMail/1.4.3 |
On Wednesday 12 February 2003 08:42 am, Gopal V wrote:
> Hey All,
> I was looking at some IL code from somewhere which used a large
> struct of about 40000 bytes which was causing StackOverflowExceptions
> for ilrun. I did what every bug hunter does -- wrote a binary search
> test suite to hit upon the magic number where the bug starts . So here
> it is .
>
> char big[32732]; // works
> char very_big[32733]; // StackOverflowException
The size of a thread's stack is fixed at startup time, as realloc'ing it is
not an option - any managed pointers to variables on the stack would point at
dead air after the realloc, leading to crashes. The size can be adjusted
with a command-line option to ilrun.
I suspect that you were probably testing GCC.NET, which allocated a huge array
on the stack to act as the program heap. I already suggested to the author
that it would be better to use Marshal.AllocHGlobal for something that big.
> What could be a good solution to this problem ? ..
We could perhaps add some detection code to the CVM coder that looks for large
local variables and moves them out into the heap. e.g. instead of allocating
the variable directly in the stack, it stores a pointer to a GC-allocated
block in the stack. Then, all of the local variable instructions on that
variable will need to be altered to access the variable indirectly through
the pointer.
That won't solve all stack overflow issues. It is still possible that a
legitimate program could use up all of stack space with small variables and
still want more. We'd need some kind of "realloc in place" to grow the stack
without moving it, and I don't think libgc has one of those.
Alternatively, we could allocate the stack as a linked list of sections, but
that would require a _lot_ of work and may be too hard at the moment.
Cheers,
Rhys.