If I run this program repeatedly, why the last number printed before seg-fault varies?

Question

The question is about how linux handle the stack. Why is not deterministic when I get segmentation-fault running this code?

#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>

void step(int n) {
    printf("#%d\n", n);
    step(n + 1);
}

int main() {
    step(1);
    return 0;
}

Answer 1

Looks like non-deterministic results is a consequence of environment randomization policy that kernel uses when starts new program. Lets try next code:

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>

int main(int argc, char **argv) {
    char c;
    uintptr_t addr = (uintptr_t)&c;
    unsigned pagesize = (unsigned)sysconf(_SC_PAGE_SIZE);
    printf("in-page offset: %u\n", (unsigned)(addr % pagesize));
    return 0;
}

On my 64-bit Linux it gives next output:

$ ./a.out
in-page offset: 3247
$ ./a.out
in-page offset: 2063
$ ./a.out
in-page offset: 863
$ ./a.out
in-page offset: 1871

Each time c gets new offset within its stack page, and knowing that kernel always allocates discrete number of pages for stack - it is easy to see that each time program has slightly different amount of allocated stack. Thus program described in the question has non-constant amount of stack for its frames per each invokation.

Being frankly I'm not sure if it is kernel who tunes initial value for stack pointer or maybe it is some trick from dynamic linker. Anyway - user code will run in randomized environment each time.

Answer 2

Because a stack overflow is Undefined Behaviour. An implementation is free to test that it does not occur, in which case the program should end with error when the stack is full. But the environment could also provide a stack with a size depending on the free memory. Or more probably you could get various memory overwriting problem in interaction with the io system which could be non deterministics. Or... (essentially UB means that anything could happen).