The fiasco is within pcrecpp.

If we make an RE object too soon, it will reference some internal global state in the RE::Init pseudo-constructor, which might not yet be initialized. This benchmark is getting ProcessInfo at static init time, which gathers a lot of process metadata.

BENCHMARK_REGISTER_F(CacheLatencyTest, BM_CacheLatency)
    ->RangeMultiplier(2 * 1024)
    // Loop over arrays of different sizes to test the L2, L3, and RAM latency.
    ->Range(256 * 1024, 4096 * 1024)
    ->ThreadRange(1, ProcessInfo::getNumAvailableCores());

This call to getNumAvailableCores is the culprit. That function isn't currently safe at static init time.
It incidentally causes an RE to be made for parsing the /proc/mountinfo file, before RE's static default_options object is initialized.
This is a pcrecpp internal bug, and a fix should be upstreamed.

https://github.com/vmg/pcre/blob/master/pcrecpp.cc#L86

static RE_Options default_options;

referring to this in a static initializer is an init-order fiasco trigger.