Comment 40 for bug 1472755

Yes, I saw. It's caused by a global singleton object in boost::log. The crash happens due to ordering issues with global destructors. The only known fix would be to hold a boost::log instance in scope for the duration of main(). However, that's not possible because we have custom scope runners for Go and JS, for one.

boost::log is garbage and completely unusable in libraries without messing with the global program state. I'm going to rip it out, but haven't found the time to do this yet.

For what it's worth, the crash happens after returning from main() so, as far as the user is concerned, there is no problem. But it still needs doing (and the wasted bandwidth and battery for the crash dump are not nice).