dotgnu-general
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]