Error: Initialization sanity check failed. Bitcoin Core is shutting down. #4945

I'm getting this error after a clean build from master on Mac OS X 10.6.8.

debug.log output after 3 runs:

2014-09-19 03:32:32 Error: Initialization sanity check failed. Bitcoin Core is shutting down.
2014-09-19 03:32:32 Shutdown: In progress...
2014-09-19 03:32:32 StopNode()
2014-09-19 03:32:33 Shutdown: done
2014-09-19 03:33:04 Error: Initialization sanity check failed. Bitcoin Core is shutting down.
2014-09-19 03:33:04 Shutdown: In progress...
2014-09-19 03:33:04 StopNode()
2014-09-19 03:33:04 Shutdown: done
2014-09-19 03:33:10 Error: Initialization sanity check failed. Bitcoin Core is shutting down.
2014-09-19 03:33:10 Shutdown: In progress...
2014-09-19 03:33:10 StopNode()
2014-09-19 03:33:10 Shutdown: done

I tried with an empty data directory and got the same results. Any ideas of what I could be doing wrong?

Have you seen it before with other builds? Have builds ever worked in this environment? Has your build environment changed? Does 0.9.3rc2 work? Need something to go on here...

I've seen some of our sanity checks fail on OSX (as intended) when I screwed up my toolchain (libstdc++ vs libc++ abi incompatibilities).

What's unique about your build env? My first guess (complete stab in the dark) would be that you've built against a newer sdk without specifying 10.6 back-compat. Newer SDKs change libstdc++ symbol visibility so that exceptions aren't caught at runtime in older environments. That causes the exception to not be caught here, so we bail.

Again, just a complete guess. Fwiw, I just tested a master build on 10.9 and all is good, but that means little in this context.

Noting for completeness because I meant to verify when I was getting these crashes, but I never did:

According §21.4.5, std::out_of_range must be thrown for a std::string::at(pos) when pos >= size().

At the error that causes us to bail, we do catch something, but it's not std::out_of_range. I had a tiny suspicion that apple's c++ runtime might've been doing something unusual but legal and we should maybe relax the constraints, but that's not the case.

All of that to say... if we don't catch that exception, shutting down is certainly the correct response. Probably 100% unrelated here, this just reminded me to verify.

@theuni thanks for your help. Answering your questions:

• Have you seen it before with other builds? No. First time I get this error. It's also the first time I build bitcoin on OS X and on this machine.
• Have builds ever worked in this environment? Has your build environment changed? No. First time I try.
• Does 0.9.3rc2 work? I left the machine compiling 0.9.3rc2 at home, will report results later

Please try the release binaries as well. First step is to narrow down whether the problem is your runtime environment or your build environment.

I already ran the release binaries yesterday (Bitcoin-QT.app) and they worked. Can I run the bitcoind command with the release version? I'm just trying to build to get the bitcoind, bitcoin-cli, etc binaries. I didn't find them on my machine (I'm not experienced with OS X) and google didn't help

@maraoz I don't think so. There is a long-standing issue about bitcoind on MacOSX: #664.

@laanwj Ah, I didn't realize that was desired. We build a deterministic bitcoind/cli for OSX, then we throw them away. No reason why we couldn't drop it in the dmg, or package them separately. @maraoz did your self-builds of rc2 work?

@theuni It would be a great idea to include bitcoind into the OSX bundle. I haven't tried the rc2 build yet, sorry. Will update later today

Nope. same results with rc2. "Error: Initialization sanity check failed. Bitcoin Core is shutting down."

Anything I can do to help fix this?

Ok, so it's your build environment then. Could you please describe in detail how you've built? Installed SDKs, toolchain used, where the dependencies came from, configure options and paths you used, etc.

@theuni I followed this instructions exactly: https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md I'm quite a newbie with Mac, so is there any specific info you'd like me to share, I'd be happy to share it, but I don't know what is important

@maraoz I suppose you're using the homebrew deps, and I'm not exactly sure how they're built.

Could you please try building the dependencies using our internal mechanism, then building bitcoin with them? If it fixes your problem, I'll go ahead and add the documentation for using them. This is how we build releases, so it should give you the same results as our released binaries. If that fixes your problem, we can either stop there, or compare the results to see why your homebrew deps aren't working.

from bitcoin srcroot:

make -C depends
./autogen.sh
./configure --prefix=`pwd`/depends/x86_64-apple-darwin*
make

The first step will take quite a while. It will fetch all of the dependency sources and build them from scratch.

There may be some issues related to 10.6 as it hasn't been tested there (which is why there aren't any docs yet).

@theuni Running make -C depends throws this error:

make: *** depends: No such file or directory.  Stop.

I searched for the depends dir and couldn't find it. I also tried to read the Makefile to see how to build the dependencies, but I'm lost. Any ideas?

@maraoz probably you're trying it on a release - depends only exists on master

@laanwj Ah, thanks. I'm getting a weird error now:

$ make -C depends
Building boost...
sh: --: invalid option
Usage:  sh [GNU long option] [option] ...
    sh [GNU long option] [option] script-file ...
GNU long options:
    --debug
    --debugger
    --dump-po-strings
    --dump-strings
    --help
    --init-file
    --login
    --noediting
    --noprofile
    --norc
    --posix
    --protected
    --rcfile
    --restricted
    --verbose
    --version
    --wordexp
Shell options:
    -irsD or -c command or -O shopt_option      (invocation only)
    -abefhkmnptuvxBCHP or -o option
error: darwin initialization: parameter 'version' inconsistent
error: no value was specified in earlier initialization
error: an explicit value is specified now

make: *** [/Users/admin/bitcoin/depends/work/build/x86_64-apple-darwin10.8.0/boost/1_55_0-df812296994/./.stamp_built] Error 1

Sounds like an undefined variable, but I couldn't find the problem. Is there anything I need to do first? By the way thanks for all the help, I hope this is useful for you too!

@maraoz sounds like the start of some 10.6 troubles. See your ping on IRC. If you're willing to step through the process, it would be very helpful.

Apple doesn't support 10.6 any more, and I don't think we should, either: http://tinyurl.com/l2rywzl

@gavinandresen A while back I suggested the possibility of requiring 10.9+ for building Bitcoin 0.10, as that seems to be Apple's line in the sand for lots of new stuff. 10.x (whatever we decide) could still be supported at run-time.

Does that seem reasonable, or too big of a leap?

@theuni : For building, I think we want to support latest-1 and latest. So right now that would be OSX 10.8 and 10.9. We certainly don't want to be require that everybody upgrade to the very latest OS as soon as it is released....

For runtime, I'd say follow the OS vendor's support policy. We really don't want to encourage people to run Bitcoin on operating systems that are no longer receiving security updates.....

@gavinandresen Newer is not always better. OpenSSL 1.0.1 proved that with Heartbleed. Newer code doesn't always fix older issues (Shellshock existing for decades unnoticed). You should also read up a bit on OSX. Some people cannot upgrade due to 10.8+ being 64 bit only. They shouldn't have to get a new computer to be able to use the default Satoshi client. Many people still use older machines too. I personally have a early netbook running Windows XP with Armory. Dropping support could push away newcomers as well (if the blockchain size doesn't).

tl;dr: Bad idea to drop support for "legacy" operating systems when a lot of people may use them on offline machines and/or may not be able to upgrade their machines.

@XDB-Asura I'm not sure where you came from or why you suddenly complain here, but FYI this is only about build-time, not run-time.

@laanwj I never knew that issues booting up a program wasn't in fact run-time. Regardless, Building/compiling or running, it should be compatible for BOTH on older machines. Not really complaining as it doesn't affect me really, just bringing up legitimate points. Is that considering complaining now?

I had the same problem on old machine, 10.6.8, gcc version 4.2.1 (Apple Inc. build 5666) (dot 3).

Oct 30 12:44:35 <paveljanik> PJ: memcpy_test[00] = 01 Oct 30 12:44:35 <paveljanik> PJ: memcpy_test[01] = 01 Oct 30 12:44:35 <paveljanik> PJ: memcpy_test[02] = 02

Ie. the array is initialized wrongly. Do not use such compiler for crypto stuff...