V7 Unix had no stack size limit, and when Unix acquired one

October 10, 2021

Famously, modern Unixes by limit the (default) size of the main process stack and the size of thread stacks; they pick different limits, which causes issues because C has no way of dealing with this. Today, for reasons beyond the scope of this entry, I became curious if V7 had any stack size limit and if it didn't, when such a limit appeared.

The short answer about V7 is that V7 had no stack size limit. The combination of your stack and your program's data (and perhaps your program's code, depending on the model of PDP-11) could take up all of the 64 KB of memory available to your process for this. If your process took a memory access fault and its stack pointer was below the kernel's idea of the bottom of your stack, the kernel automatically grew the stack as far as necessary. You can see this in the V7 trap.c, where the decision to grow is made, and sig.c, which has the routine for the growing (and also ureg.c for one additional function).

On the BSD line of Unixes, 3BSD doesn't seem to have anything but 4BSD introduces a vlimit(2) system call to get and set limits, including the stack size. By 4.1c BSD, this has changed to the now familiar getrlimit(2) and setrlimit(2) system calls.

(Interestingly, Linux glibc provides a vlimit(), according to the manpage.)

On the AT&T side, there doesn't seem to be anything much that I could find. The System V Interface Definition (SVID) seems to be the official source of a ulimit() system call, but its only official thing is limiting file size. As far back as System III, there is a ulimit(2), but it doesn't set the stack size limit; the closest it comes is that it can get (but not set) the brk(2) limit. The System III VAX trap.c and sig.c still seem to be free of stack size limit checks, and have comments that say things are grown unconditionally.

(The current Oracle Solaris ulimit(2) manual page still talks about being able to get the maximum possible break value, although this isn't required in POSIX.)


Comments on this page:

By frankg at 2021-10-10 01:42:26:

v7 would allocate contiguous memory to the stack immediately if available. If it was not the process would be swapped out with stack size adjusted so when the process was swapped back it had the new size. System III still used the same technique (see expand in slp.c). Unixes that don't implement process swapping would not be able to use this method of growing the stack.

By Andrew at 2021-10-11 00:39:43:

I always thought the only reason for a stack size limit was threads (each thread within a process needs a discrete VM space for its stack so they don't step on one another, and if your addresses are 32-bit or less, and you might have a large number of threads, then you can't afford very much stack space at all per thread... particularly if you want to have any left over for the heap).

Written on 10 October 2021.
« We've migrated from Yubikey 2FA to the university's MFA
TLS Certificate Transparency logs let us assess Certificate Authorities »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Oct 10 00:14:45 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.