I included the crasher that @jeromekelleher provided in gh-31415 as a test. By increasing n_cols to 10, I could get the crash to occur with high probability even with the duration of the test reduced to 2 seconds. Still, I'm not sure we want to include this in the test suite.

Thanks for the speedy fix @WarrenWeckesser ❤️

Still, I'm not sure we want to include this in the test suite.

We may want to have a multi-threaded test, but not with explicit time.sleep(2). There must be better patterns already in the test suite already, probably @ngoldbaum can point at an example here.

We may want to have a multi-threaded test, but not with explicit time.sleep(2). There must be better patterns

Was just confirming that it works: But we don't need any threading at all. We just need to add a parametrization for existing tests with >500 elements or so (let's do 2000 maybe).

We have debug test runs in the test-suite, and these already hit it reliably, the only problem is that the tests don't cover larger tests.
(May be nice to also add to other tests generally, e.g. unique or some ufuncs)

But we don't need any threading at all. We just need to add a parametrization for existing tests with >500 elements or so (let's do 2000 maybe).

Which tests are those?

The TestStringLikeCasts will do the trick (we use it for bytes casting).

EDIT: E.g. ["short", "12345678"] * 1000, works...

I removed the multi-threaded test and added the test case suggested by @seberg.

Thanks Warren!

@ngoldbaum, thanks for finding my mistake 😳.

No problem, I really appreciate you taking on the fix :)