Synchronize dbghelp with the standard library

[alexcrichton]

The dbghelp library on MSVC is not safe to use concurrently from multiple threads. There is no synchronization between the standard library's usage of RUST_BACKTRACE=1 and this crate generating a backtrace, meaning that it's not technically possible to 100% safely use this crate on MSVC.

Fixing this will likely require some form of global lock exported by the standard library specifically for backtraces and specifically for MSVC (it can be a noop on all other platforms). This library would then, when compiled on crates.io, need to coordinate with the standard library in terms of locking to ensure that only one implementation is using dbghelp at a time.

[arsing]

This also causes heap corruption crashes currently if both libstd and a user crate take backtraces at approximately the same time. This happens with one of our crates' tests very reliably, where one test happens to run an assert!() (which triggers libstd backtrace collection) at about the same time as another test creates a failure error (which collect its own backtrace).

I happened to spot StackWalkEx in the crashing thread's backtrace, but I assume it would happen even with the older backtrace crate that solely used StackWalk64 ? So just downgrading the backtrace crate would not be useful unless we also used an older Rust that didn't use the backtrace crate?

[alexcrichton]

Yes this unfortunately has always been a bug with the backtrace crate, no version has ever had this bug fixed. This is definitely a case where binaries can segfault because the documentation of Windows explicitly states that it needs synchronization, and we're not doing that! It "just so happens to work" most of the time because it's relatively rare to get two backtraces at the same time.

[alexcrichton]

I've posted a possible mitigation for what I'd hope is 90%-ish of cases at #241