I'm currently working on updating the mongodb crate's tests to run with the --test-threads 1 option to eliminate the need for a test lock. In the process of testing these changes in our CI, I've run into some stack overflow failures in our more substantial tests, specifically when testing the driver on Windows with the async-std runtime via the async_std::test macro. I'm curious if anyone has any understanding of why 1) running a test suite single-threaded would cause stack overflows to happen and 2) why this happens specifically when using the async-std runtime rather than tokio. Has anyone run into similar issues when running a single-threaded test suite? Thanks!
When you specify --test-threads 1 the test harness skips spawning new threads, and instead runs all tests on the main thread. Both tokio and async_std use the currently running thread for their test macro rather than spawning new ones, so you're still running on main.
The reason that matters is that the program has no control over how much stack space is allocated for its main thread. It does however have control over how much stack space is allocated in newly spawned threads. So when the test runtime is spawning a new thread for each test, the thread has more stack space (anecdotally Windows seems particularly stingy about how much stack space the main thread gets, because I've hit a similar issue before). You can also set the stack size new threads spawned by std will have with the RUST_MIN_STACK environment variable
As for why tokio is working fine, some extremely unscientific testing shows that in debug builds tokio seems to call slightly fewer functions between the actual generated test function and the async body of the test. So your test is probably close to an overflow anyway on main and async_std's slightly heavier initialization is just pushing it over the edge.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.