Set worker thread stack size to match the main thread - #9158
Open
guybedford wants to merge 1 commit into
Open
guybedford wants to merge 1 commit into
guybedford wants to merge 1 commit into
Conversation
std::thread uses the platform default stack size for new threads, which on macOS is only 512KB for secondary threads regardless of ulimit -s. Deeply recursive passes on large functions therefore overflow in ThreadPool workers and crash with SIGBUS on macOS, while passing on Linux (where glibc sizes new threads from RLIMIT_STACK) and Windows (where the linker /STACK applies to all threads). On POSIX, create workers with pthread_create and an explicit stack size taken from the RLIMIT_STACK soft limit (8MB if unlimited), so workers can recurse as deeply as the main thread and ulimit -s applies to them too.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes a SIGBUS in
wasm-opton macOS when optimizing large modules with deeply recursive passes in parallel.I've directly verified that this fix fixes a SIGBUS on a large (35MiB) binary on MacOS that I was hitting this issue on.
std::threaduses the platform default stack size for new threads. On macOS that is a fixed 512KB for secondary threads regardless ofulimit -s, so at-O2/-Oson large functions theThreadPoolworkers overflow their stack. The same module and flags pass on Linux, where glibc sizes new threads fromRLIMIT_STACK, and on Windows, where the linker/STACKreserve already applies to all threads.BINARYEN_CORES=1also passes since the work then runs on the main thread.Threadnow creates workers withpthread_createand an explicit stack size viapthread_attr_setstacksize.getWorkerThreadStackSize()uses theRLIMIT_STACKsoft limit, falling back to 8MB when unlimited, so workers can recurse as deeply as the main thread andulimit -sapplies to them too. This matches the existing glibc behavior, so Linux is unchanged.std::thread.Test coverage: a new
ThreadsTest.WorkerStackSizegtest runs work on every pool thread and asserts the actual worker stack size is at least the requested size. It passes on Linux today and would fail on macOS without this change (verified by forcing a 512KB worker stack locally, which fails with524288 vs 8388608).Made with AI assistance under my review