Currently the default for MinGW builds is to enable lazy locking (e.g. --enable-lazy-lock to the configure script), but it seems problematic for Windows. The isthreaded global variable indicates whether threads are active and locks should be used, but this is only set to true on a DLL_THREAD_ATTACH event on Windows (unlike on Unix where pthread_create is hooked).

According to Windows, however, "the call is made in the context of the new thread", and I believe this means that problems can later arise. For example, if thread A uses jemalloc, spawns thread B, then uses jemalloc some more, it could be the case that thread A enters a jemalloc critical section before thread B has used jemalloc, meaning it doesn't grab a lock. Later on thread B uses jemalloc, enabling future calls to locking functions. If thread A then exits the critical section, it will attempt to unlock a not-locked mutex, causing the process to abort.

I think this means that lazy locking isn't possible on Windows to do reliably, and perhaps the default for MinGW should be switched back? The default was enabled after #83 was filed in 13473c7 but #83 didn't look like it ever came up with concrete evidence to why lazy locking was at fault, and it looks like a number of initialization changes to mutexes in jemalloc has changed in the meantime, so it's likely that this has been fixed under the hood.

We discovered this when updating Rust to use jemalloc 4.0.0 after a few failed attempts which all seemed to bounce for spurious reasons.

Unfortunately I haven't been able to come up with a nice succinct test case to reproduce this. My current threshold is "checkout Rust, update jemalloc, build, run one test 100 times and it'll die at least once". I can try to reduce this down, however, if it would help! I figured I'd try to run the idea of lazy locking by here first though.