elements: Client Crashes with sendtoaddress
After updating elementsd on regtest crashes when trying to sendtoaddress.
Log spits out:
2019-11-16T00:47:30Z Received a POST request for / from 127.0.0.1:50217
2019-11-16T00:47:30Z ThreadRPCServer method=getnewaddress user=user2
2019-11-16T00:47:30Z [default wallet] keypool reserve 3
2019-11-16T00:47:30Z [default wallet] keypool keep 3
2019-11-16T00:47:30Z Received a POST request for / from 127.0.0.1:50218
2019-11-16T00:47:30Z ThreadRPCServer method=sendtoaddress user=user2
2019-11-16T00:47:30Z [default wallet] keypool added 1 keys (0 internal), size=2000 (1000 internal)
2019-11-16T00:47:30Z [default wallet] keypool reserve 1001
2019-11-16T00:47:30Z [default wallet] Unblinding single blinded output at index 0 due to lack of inputs and other outputs being blinded.
Then in the terminal:
error: Could not connect to the server 127.0.0.1:18885 (error code 1 - "EOF reached")
This happens every time when doing the tutorial.
Bitcoin Core Version: 0.18.99.0
MacOSX 10.15.1
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 39 (12 by maintainers)
Commits related to this issue
- ci: fiddle with macos CFLAGS to work around apparent clang bug See https://github.com/ElementsProject/elements/issues/782 — committed to apoelstra/elements by apoelstra 4 years ago
- ci: fiddle with macos CFLAGS to work around apparent clang bug See https://github.com/ElementsProject/elements/issues/782 — committed to apoelstra/elements by apoelstra 4 years ago
- ci: fiddle with macos CFLAGS to work around apparent clang bug See https://github.com/ElementsProject/elements/issues/782 — committed to apoelstra/elements by apoelstra 4 years ago
- Squashed 'src/secp256k1/' changes from 43dd1f4fe7..0129b77767 0129b77767 Merge #113: Upstream PRs #849 #851 e1756dfddc Merge commits '3a106966 8f0c6f15 ' into temp-merge-851 7093e633b8 Merge pull re... — committed to ElementsProject/elements by apoelstra 4 years ago
- Squashed 'src/secp256k1/' changes from 8ab24e8dad..c6b6b8f1bb c6b6b8f1bb Merge #830: Rip out non-endomorphism code + dependencies c582abade1 Consistency improvements to the comments 63c6b71616 Reorde... — committed to ElementsProject/elements by sipa 4 years ago
- ci: fiddle with macos CFLAGS to work around apparent clang bug See https://github.com/ElementsProject/elements/issues/782 — committed to apoelstra/elements by apoelstra 4 years ago
- Merge ElementsProject/elements#1001: Adds an -fno-stack-check compile time flag to OSX local builds 43657b5aaa31036383556d70f5b7408b7e3fac7b Adds an -fno-stack-check compile time flag to OSX local bu... — committed to ElementsProject/elements by stevenroose 3 years ago
FWIW, I don’t think we have anybody on the team with both the right OS X version to repro this, and the right expertise to work on it, especially given that it doesn’t affect the release binaries (which are cross-compiled, and don’t exhibit the problem, which is presumably related to the toolchain on the particular version of OS X.)
I don’t want to ignore this, because it’s possible that it reflects some latent UB that just happens to only reproduce on this one toolchain, but it also doesn’t seem likely that it’s going to get the kind of attention it needs for a fix in the near future.
Are you in a position where it’s critical to be able to build from source on Catalina, vs using release binaries or cross-compiling? I don’t want to put you off if you really need this fixed, but there’s also not a super straightforward path to debugging it further given available resources, it seems.
If one of you who can reproduce the problem wants to dive into it further, I’m happy to provide support as much as I can without access to the offending system. Or if someone wants to give us access to a Catalina system we can play around on to try to debug further.