net@tub.UUCP (Oliver Laumann) (08/08/90)
Is there a way for a program to determine the maximum stack size of a
process on systems that don't support getrlimit(RLIMIT_STACK), such
as POSIX-, SVID-, or X/Open-systems? ulimit(2) doesn't seem to have this
functionality. If you don't know the general answer-- do you know if
and how this can be done under HP-UX?
If this functionality doesn't exist, does this mean the stack of a process
can grow indefinitely?
Thanks,
--
Oliver Laumann, Technical University of Berlin, Germany.
pyramid!tub!net net@TUB.BITNET net@tub.cs.tu-berlin.debogatko@lzga.ATT.COM (George Bogatko) (08/09/90)
> ...does this mean the stack of a process > can grow indefinitely? On 3B's it does. How did we find this out? We had a 3B that was tuned (by default!) so that MAXUMEM was *greater* then available swap. MAXUMEM was tuned to be ALL the available memory which was about 16 meg, The default swap area is 20640 blocks, or about 10.5 meg. A user program had the following line in it: func() { char buf[100]; . . strncpy(buf, str); . . } Notice that it is strNcpy, and that the last parameter is missing. This meant that a stupid value was passed as the third parameter, which told strncpy to copy a huge number into buf. Notice that 'buf' is an AUTOMATIC array, which means it is on the stack. Well, the result was that the machine slowed down real fast, soon you couldn't get prompt from the *console*, then finally, the machine PANIC'd and dumped core. This happened because the stack (by definition, at least on this machine) grew and grew and GREW and grew, until the process size was greater then what could be held on the swap device. Then the machine broke. You can force the same condition (not recommended folks, don't just TRY this) with: strncpy(buf, str, 0x7fffffff); The fix (highly recommended) was to reset MAXUMEM from it's FACTORY DEFAULT of ALL AVAILABLE MEMORY to something less than swap size. When the same program was run, it still slowed down the machine real bad, but eventually core-dumped. BTW, the same thing, tried on our 386 machine just core-dumped. I suppose they don't just grow the stack. Replys i386 gurus? GB
guy@auspex.auspex.com (Guy Harris) (08/10/90)
>Is there a way for a program to determine the maximum stack size of a >process on systems that don't support getrlimit(RLIMIT_STACK), such >as POSIX-, SVID-, or X/Open-systems? Not all POSIX-compliant, SVID-compliant, or X/Open-compliant systems lack "getrlimit()"; in fact, SVID Third Edition-compliant systems *have* to support "getrlimit(RLIMIT_STACK)" (as well as RLIMIT_CORE, RLIMIT_CPU, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_NOFILE, and RLIMIT_AS). Neither POSIX, nor X/Open, nor SVIDs prior to the third edition specify any say of finding this information out, so if you're trying to write something that will work on *any* POSIX-compliant or *any* X/Open-compliant or *any* SVID-compliant system, you're out of luck. >If you don't know the general answer-- do you know if and how this can >be done under HP-UX? HP-UX does support "getrlimit()"? If there were such a mechanism, and they didn't stuff it into "ulimit()", I'd expect HP to stuff it there. If it's not there, you may be out of luck. >If this functionality doesn't exist, does this mean the stack of a process >can grow indefinitely? Err, no, you eventually run out of address space.... What other policies a particular UNIX implementation puts on the stack depend on the implementation, so there really aren't any hard-and-fast guarantees.