bitcoinarmory segfaults in nixos-unstable

[michalrus]

Issue description

@elitak

After installing bitcoinarmory, this happens:

$ ArmoryDB --version
zsh: segmentation fault  ./ArmoryDB --version

$ file -L $(which ArmoryDB)
/run/current-system/sw/bin/ArmoryDB: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /nix/store/q0prbrw9n7h2sjqmla8ac32lfyq0w91z-glibc-2.25-49/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped

$ ldd $(which ArmoryDB)
        not a dynamic executable

Steps to reproduce

1. Install bitcoinarmory from nixos-unstable — c8e7aab.
2. Run ArmoryDB --version.

Technical details

• System: 17.03.1844.83706dd49f (Gorilla)
• Nix version: nix-env (Nix) 1.11.14
• Nixpkgs version: "17.03.1844.83706dd49f"
• Sandboxing enabled: build-use-sandbox = true

[michalrus]

Also, upstream made 2 releases since, one with a critical vuln.

[elitak]

I'm getting the same on 0.96.3, but will look some more. What specifically is the vulnerability, out of curiosity?

[elitak]

The upstream build process in still quite messy, with embedded libraries concretely integrated into build files. I've got a modified nix expression that replaces some of the deps with libs in the store, but with both variants I still get either a SegFault in ArmoryDB or a SIGILL in _CppBlockUtils.so. I don't know if I can invest much more time in fixing this. I suspect the issues originate upstream, FWIW.

Personally, I'm running a gcrooted-closure that I've kept unchanged for some months now.

[michalrus]

I’m not sure, 0.96.3 works fine with <nixpkgs> from your original commit, i.e. e93fe9a.

The vulnerability was related to fragmented backups.

Well, I guess I’ll just stay with Bitcoin Core. I just wanted to try this one. ¯\_(ツ)_/¯

[elitak]

Oh, interesting. This isn't the first time I've seen a newer glibc cause segfaults and other nastiness, but I lack the skill to fix these types of problems efficiently.

Armory's great for the offline wallet stuff, but the original devs left the source tree in a poor state. I'll eventually get it working on the master branch again, probably.

[michalrus]

I don’t get that, really. Is everything compiled from source in this derivation? Does upstream include binary blobs in the repo? :\

[michalrus]

Both that SIGSEGV at the very beginning, and ldd failure, and SIGILL would suggest a linking error to me. You shouldn’t need to use patchelf on programs cleanly built from source. Hmm.

[michalrus]

Even less so, to remove a /tmp reference? What is this upstream build script doing? 😁

*sighs*

[elitak]

It's building the lib deps from source. fcgi is a git-submodule and the rest are checked into the repo. I've already begun to try to excise them during the patch phase: elitak@ff1c2a9 This still yields the same problems, however, along with some new ones (fcgi version mismatch, i think), but it's on the path to getting a cleanly linked binary. I welcome any amendments to get this working reliably and linked properly.

[michalrus]

Let me try that, but that upstream repo is a total mess.

[michalrus]

⬆️ fixed above.