collapsing forks

der Mouse mouse at thunder.mcrcim.mcgill.edu
Sun Jun 2 05:44:49 AEST 1991


In article <MYCROFT.91May29194828 at kropotki.gnu.ai.mit.edu>, mycroft at kropotki.gnu.ai.mit.edu (Charles Hannum) writes:
> In article <1991May24.215945.13707 at ddtg.com> pechner at ddtg.com (Michael Pechner) writes:
>> I am having a very strange problem with A/UX.  I can cause a fork to
>> "sort of" fail by having a huge automatic variable.
>>	   main(){
>>		   char junk[256000];
>>		   /*...*/
>>	   }
> In the second example, 'junk' is indeed being allocated as an
> automatic variable.  Most C compilers cause this data to be placed on
> the stack.  For some reason, tossing 250K on the stack at once gives
> A/UX indigestion, and your program dies.

This is generally an interaction of wild-pointer detection and
automatic stack growth.  I can't speak about A/UX specifically, but I
have seen systems that do act as I'm about to describe.

The problem is that we want to grow the stack automatically as
necessary.  This is done by the memory-fault handler: it simply grows
the stack to encompass the out-of-bounds access.

But there's a conflict: an access through a random pointer shouldn't
result in the stack being grown by gigabytes to encompass the
reference.  So there's a (relatively) small window.  Stack accesses off
the end of the stack, but not too far off the end of the stack, cause
stack growth; accesses too far beyond the end of the stack produce
memory violation faults.

So that quarter-meg of stack growth in one jump is probably enough that
the next stack access oversteps this window.

One possible patch is

	char junk[256000];
	int i;
	for (i=0;i<256000;i+=1000) junk[i] = 0;

where you may need to declare i before junk, and you may need to access
junk backwards, depending on your compiler and your machine.  (The
declaration order depends on how the compiler arranges variables on the
stack; the access order depends on whether your stack grows up or
down.)  This generates accesses that extend the stack gradually instead
of all at once.  Of course, if the function entry prologue code does
stack accesses after allocating automatic variable space, you're sunk
without a trace no matter what you try.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu



More information about the Comp.unix.wizards mailing list