Xref: utzoo comp.unix.aux:4779 comp.unix.wizards:25834 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse From: mouse@thunder.mcrcim.mcgill.edu (der Mouse) Newsgroups: comp.unix.aux,comp.unix.wizards Subject: Re: collapsing forks Message-ID: <1991Jun1.194449.25234@thunder.mcrcim.mcgill.edu> Date: 1 Jun 91 19:44:49 GMT References: <1991May24.215945.13707@ddtg.com> Distribution: usa Organization: McGill Research Centre for Intelligent Machines Lines: 51 In article , mycroft@kropotki.gnu.ai.mit.edu (Charles Hannum) writes: > In article <1991May24.215945.13707@ddtg.com> pechner@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@larry.mcrcim.mcgill.edu