Thanks for finding the solution. I am wondering if we should add a short comment about it, but not super important.
Ping @ngoldbaum if just because it might be interesting to him.

I do wonder if the armhf failure may be real though :(.

Thanks for finding the solution. I am wondering if we should add a short comment about it, but not super important.

I added a comment with link to the gcc issue.

It looks like the armhf tests are using gcc 13.3, in case it helps. The tests crash on test_arrayprint which has a multithreaded test, so I bet this is related.

Hmmm, could it be that we have to explicitly initialize available to zero now!? (just wondering what the heck could in theory fail...)

It failed again with a crash. Not sure how to debug it on such a platform.

I am guessing it might be because sizeof(tls_cache) = 66560UL which might be too large for a single allocation or something on armhf

I am guessing it might be because sizeof(tls_cache) = 66560UL which might be too large for a single allocation or something on armhf

Ohhh, that would make sense, but in that case we would have to split it up? Debugging it certainly won't be fun :(.

Not sure how to debug it on such a platform.

I've used the tmate action to debug stuff like this on a github runner: https://github.com/mxschmitt/action-tmate

Otherwise I think you have an ARM mac, right? You should be able to run Linux in a VM or use orbstack or some other docker environment to run ARM Linux docker containers locally on your Mac to get the armhf container the CI job uses.

It passed with splitting up the cache so it was indeed the size issue.

I'll test it once more in a bit (it worked with the earlier version, so I think it should be OK).

This large allocation erroring does make me wonder whether it would be cleaner to allocate this so that thread-local is just the pointer to the cache object?!

Backport?

No, #30499 wasn't and shouldn't be backported.

This large allocation erroring does make me wonder whether it would be cleaner to allocate this so that thread-local is just the pointer to the cache object?!

That might be a little slower because statically allocated blocks have better locality than block allocated on heap, given that it is not an issue on major platforms I don't think we should change it.

Thanks for the multiple follow-ups on this one @kumaraditya303. Surprisingly weird/tricky/subtle!