GH-113655: Lower the C recursion limit for some platforms

[thesamesam]

• Issue: Stack overflow collecting PGO data on Windows #113655

Lower the C recursion limit for HPPA, PPC64 and SPARC, as they use
relatively large stack frames that cause e.g. test_descr to hit
a stack overflow. According to quick testing, it seems that values
around 8000 are max for HPPA and PPC64 (ELFv1 ABI) and 7000 for SPARC64.
To keep things safe, let's use 5000 for PPC64 and 4000 for SPARC.

Co-authored-by: Sam James [email protected]

[vstinner]

Please add a comment explaining why big endian has a lower limit, with gh-113655 reference.

[vstinner]

We currently reduce the C recursion limit just for s390x (which is big-endian), but in Gentoo, we hit the same issues on ppc64be, hppa, and sparc.
At least for ppc64, it seems like the ABI used on ppc64be means you end up with bigger stack frames.

That's strange that all big endian archs allocates more memory on the stack. What can explain that only big endian archs are affected?

[mgorny]

I think it's a coincidence, and the logic is more related to the fact that big endian architectures aren't tested much. Perhaps the more appropriate logic would be to have a "more conservative" value in the default branch, and make it higher for platforms that we know are safe.

[mgorny]

Ok, so I've played a bit with godbolt and got the following numbers for a dummy function with no args or variables:

• ARM (32-bit): 8 bytes (BE/LE)
• AArch64: 16 bytes (BE/LE)
• x86: 8 bytes (+ 4 bytes in 32-bit programs)
• LoongArch: 16 bytes
• MIPS: 24/32 bytes (depending on ABI, BE/LE)
• ppc64 (BE): 128 bytes
• ppc64le: 112 bytes
• ppc32: 16 bytes
• riscv: 16 bytes (32/64-bit)
• s390x: 160 bytes
• s390: 96 bytes
• SPARC: 96 bytes
• SPARC64: 176 bytes

So, looks like ppc64/s390/SPARC are the platforms with unusually large stack frames. However, I don't see any obvious relation between byte order and stack frame size here. ppc64le's is only a little smaller than ppc64 BE, so I have no clue why we're hitting the crash with one but not the other — but maybe it just happened to be on the border. On all other biendian arches, stack frame seems to be of the same size on both variants.

---

I've used the following code:

void b() {
}

void a() {
    b();
}

Tested with various compilers, compiler options (-mbig-endian, -mlittle-endian, -m32…). Enabled "Stack Usage" via "Add new…"

[vstinner]

So, looks like ppc64/s390/SPARC are the platforms with unusually large stack frames

Would it be possible to only use lower limit on these 3 archs? Rather than testing "big endian".

[mgorny]

Yeah, I suppose so. @thesamesam also mentioned HPPA, but godbolt doesn't cover that.

[mgorny]

Suggested change

	#elif defined(__BIG_ENDIAN__)
	#elif defined(__hppa__) || defined(__powerpc64__) || defined(__s390__) || defined(__sparc__)

[mgorny]

Or we could try to use different values for different arches, given that ppc64 could probably use a higher value. Probably worth double-checking SPARC64, as it has even bigger frames than s390x.

[thesamesam]

That's strange that all big endian archs allocates more memory on the stack. What can explain that only big endian archs are affected?

I saw this question just before I went to bed and my assumption (which I wanted to prove/disprove today) was that it was an unfortunate artefact of ABI design and that if we ended up looking at the ABIs for newer (and therefore LE) arches, we'd end up seeing some notable differences.

But mgorny (thank you!) beat me to it and I think his analysis is right. I'll look a bit more then update this PR. Thanks again both.

[mgorny]

Ok, now for some real hardware testing of when test_descr starts crashing. The highest recursion limits I was able to use (with regular build from main, gcc, default optimization level, GNU/Linux):

• amd64/x86/aarch64/ppc32: 32k
• ppc64 (be): 9k (8k with PGO + forced -O2)
• ppc64le: 11k
• s390x: 12k (7k with PGO + -O2)
• sparc64: 7k (also with PGO + -O2)
• pa-risc: over 10k (host too slow to test more)
• alpha: over 10k (host too slow to test more)

It looks like amd64/x86/etc. are hitting some other issue that looks like a 16-bit signed counter. The values I've gotten for PPC64 suggests that LE was on the edge already. Surprisingly, my value for s390x is much higher than the one currently used — FWICS it was lowered due to buildbots failing.

Honestly, I don't know what values to put here.

[mgorny]

@vstinner, with Sam's permission, I have pushed a commit that lowers the limits on PPC64 and SPARC instead.

[thesamesam]

Thanks! Happy now.

@vstinner Can you take another look please?

[vstinner]

Merged, thanks. The final commit is way better than the first iteration only checking for big endian ;-)

[mgorny]

Thanks a lot!