Skip to content

broken IPC on release tag sv2-tp-0.1.10-ipc #71

Closed
Closed
broken IPC on release tag sv2-tp-0.1.10-ipc#71

Description

@plebhash
plebhash
opened on Nov 29, 2024

I launched bitcoin-node via:

$ ./build/src/bitcoin-node -ipcbind=unix -testnet4

it seems to be running ok

then I launch bitcoin-mine, which breaks as soon as I try to connect a SRI pool to it:

$ ./build/src/bitcoin-mine -debug=sv2 -loglevel=sv2:trace -testnet4 -sv2port=8442
2024-11-29T15:23:43Z Ignoring unknown configuration value server
2024-11-29T15:23:43Z Default data directory /Users/plebhash/Library/Application Support/Bitcoin
2024-11-29T15:23:43Z Using data directory /Users/plebhash/Library/Application Support/Bitcoin/testnet4
2024-11-29T15:23:43Z Config file: /Users/plebhash/Library/Application Support/Bitcoin/bitcoin.conf
2024-11-29T15:23:43Z Command-line arg: debug="sv2"
2024-11-29T15:23:43Z Command-line arg: loglevel="sv2:trace"
2024-11-29T15:23:43Z Command-line arg: sv2port="8442"
2024-11-29T15:23:43Z Command-line arg: testnet4=""
Connected to bitcoin-node
2024-11-29T15:23:43Z [sv2] Reading cached static key from /Users/plebhash/Library/Application Support/Bitcoin/testnet4/sv2_static_key
2024-11-29T15:23:43Z [sv2:info] Static key: 031d7b82ac689a0b87e12b0abe927e878fb68136563dfab3e2df9da6e0dfb4dd69
2024-11-29T15:23:43Z Template Provider authority key: 9bq1mqn8BqfQmEMwsAKohN77s7YSS5K5hxw36TMBBKfAWKKpJye
2024-11-29T15:23:43Z [sv2:trace] Authority key: 9dacf485fc07a940224466ef013bec1232e630b0e61ef1c0d64048c5c183ad59
2024-11-29T15:23:43Z [sv2:trace] Certificate hashed data: 00006fce4967ffffffff1d7b82ac689a0b87e12b0abe927e878fb68136563dfab3e2df9da6e0dfb4dd69
2024-11-29T15:23:43Z [sv2:info] Template Provider listening on 127.0.0.1:8442
2024-11-29T15:23:43Z net thread start
2024-11-29T15:23:43Z sv2 thread start
2024-11-29T15:24:01Z [sv2:trace] Noise session receive state -> HANDSHAKE_STEP_1
2024-11-29T15:24:01Z [sv2:trace] New client id=0 connected
2024-11-29T15:24:01Z [sv2:trace] Read their ephemeral key
2024-11-29T15:24:01Z [sv2:trace] Mix hash: a22d2f324275944ae8237afd3d00b5d52d6f0573f0a73a62f9425c64ee3ca88e
2024-11-29T15:24:01Z [sv2:trace] Noise session receive state -> HANDSHAKE_STEP_2
2024-11-29T15:24:01Z [sv2:trace] Generate ephemeral key
2024-11-29T15:24:01Z [sv2:trace] Write our ephemeral key
2024-11-29T15:24:01Z [sv2:trace] Mix hash: 81a0a0fcc3158ed1ea1de56acde870f285047fc740c6891c5bdc948e4e0b36ad
2024-11-29T15:24:01Z [sv2:trace] Perform ECDH with the remote ephemeral key
2024-11-29T15:24:01Z [sv2:trace] Mix key with ECDH result: ephemeral ours -- remote ephemeral
2024-11-29T15:24:01Z [sv2:trace] Chaining key: 1bf1826e42479cc3d271f6845247a02193b612de6cea2b6689a8e56998e54ef0
2024-11-29T15:24:01Z [sv2:trace] Encrypt and write our static key
2024-11-29T15:24:01Z [sv2:trace] Mix hash: 323e8f710d6a28b53bc69338a0f33c4c5a47b7216383facada3108ff02898bc4
2024-11-29T15:24:01Z [sv2:trace] Perform ECDH between our static and remote ephemeral key
2024-11-29T15:24:01Z [sv2:trace] ECDH result: b2145d79410c79f7e6bcea690e8970144d7c6a6ea57e68f6a38a87f69fb3add6
2024-11-29T15:24:01Z [sv2:trace] Mix key with ECDH result: static ours -- remote ephemeral
2024-11-29T15:24:01Z [sv2:trace] Chaining key: 3fe3bc65efb2cbb76273643a6dba9b2cc6079e0809f72fbd3d569061fbb40d23
2024-11-29T15:24:01Z [sv2:trace] Encrypt certificate: 00006fce4967ffffffffeee1f11ae3181a0feefb90b409f1f1d32d7eccea0d87f56e47f4b8b32a600ff1afa780efb651dd06bb5970bfb7c2845e5287d3aed9230f0a4e648935d16c68ce
2024-11-29T15:24:01Z [sv2:trace] Mix hash: 4dc1082994eaa63737c7bfcb684385ca918e86b63fee3cf48e0425b5e0bea1ea
2024-11-29T15:24:01Z [sv2:trace] Noise session send state -> READY
2024-11-29T15:24:01Z [sv2:trace] Noise session receive state -> APP
2024-11-29T15:24:01Z [sv2:trace] Send 234 bytes to client id=0
2024-11-29T15:24:01Z [sv2:trace] Header: 000000190000
2024-11-29T15:24:01Z [sv2:trace] Expecting 25 bytes payload (plain)
2024-11-29T15:24:01Z [sv2:trace] Payload: 020200020000000000093132372e302e302e31fa2000000000
2024-11-29T15:24:01Z [sv2:trace] Noise session receive state -> APP_READY
2024-11-29T15:24:01Z [sv2:trace] Noise session receive state -> APP
2024-11-29T15:24:01Z [sv2] Received 0x00 SetupConnection from client id=0
2024-11-29T15:24:01Z [sv2] Send 0x01 SetupConnection.Success to client id=0
2024-11-29T15:24:01Z [sv2:trace] Header: 000001060000
2024-11-29T15:24:01Z [sv2:trace] Send 44 bytes to client id=0
2024-11-29T15:24:01Z [sv2:trace] Header: 000070040000
2024-11-29T15:24:01Z [sv2:trace] Expecting 4 bytes payload (plain)
2024-11-29T15:24:01Z [sv2:trace] Payload: 01000000
2024-11-29T15:24:01Z [sv2:trace] Noise session receive state -> APP_READY
2024-11-29T15:24:01Z [sv2:trace] Noise session receive state -> APP
2024-11-29T15:24:01Z [sv2] Received 0x70 CoinbaseOutputDataSize from client id=0
2024-11-29T15:24:01Z [sv2] coinbase_output_max_additional_size=1 bytes
2024-11-29T15:24:01Z 

************************
EXCEPTION: N3ipc9ExceptionE       
kj::Exception: (remote):0: failed: remote exception: std::exception: SpanReader::read(): end of data: unspecified iostream_category error
stack: 10369f7d0 102aa5e04 102aa6544       
bitcoin in sv2       



************************
EXCEPTION: N3ipc9ExceptionE       
kj::Exception: (remote):0: failed: remote exception: std::exception: SpanReader::read(): end of data: unspecified iostream_category error
stack: 10369f7d0 102aa5e04 102aa6544       
bitcoin in sv2       

libc++abi: terminating due to uncaught exception of type ipc::Exception: kj::Exception: (remote):0: failed: remote exception: std::exception: SpanReader::read(): end of data: unspecified iostream_category error
stack: 10369f7d0 102aa5e04 102aa6544
[1]    87756 abort      ./build/src/bitcoin-mine -debug=sv2 -loglevel=sv2:trace -testnet4

Activity

  1. Sjors commented on Nov 29, 2024

    @Sjors
    Sjors
    on Nov 29, 2024
    Owner

    Both bitcoin-node and bitcoin-mine were built from the same commit? To be on the safe side, can you try deleting the build dir and re-compiling?

    (this kind of error can happen if the versions don't match, because the interface isn't stable yet)

    I'll try to reproduce.

  2. Sjors commented on Nov 29, 2024

    @Sjors
    Sjors
    on Nov 29, 2024
    Owner

    I get the same... will debug.

  3. plebhash commented on Nov 29, 2024

    @plebhash
    plebhash
    on Nov 29, 2024
    Author

    Both bitcoin-node and bitcoin-mine were built from the same commit? To be on the safe side, can you try deleting the build dir and re-compiling?

    (this kind of error can happen if the versions don't match, because the interface isn't stable yet)

    I'll try to reproduce.

    the logs above were generated after building a fresh clone, which was checked out at the release tag from the issue title sv2-tp-0.1.10-ipc

  4. Sjors commented on Nov 29, 2024

    @Sjors
    Sjors
    on Nov 29, 2024
    Owner

    Running the node with -debug=ipc reveals a crash on receiving createNewBlock:

    IPC server recv request  #5 Mining.createNewBlock$Params [....]

    I narrowed it down to the scriptPubKey argument, because it still crashed when I dropped the options argument:

    2024-11-29T16:28:42.745177Z [ipc] {bitcoin-node-38256/b-capnp-loop-7165444} IPC server recv request  #5 Mining.createNewBlock$Params (scriptPubKey = "")
2024-11-29T16:28:42.745352Z [ipc] {bitcoin-node-38256/b-capnp-loop-7165444} IPC server unhandled exception: SpanReader::read(): end of data: unspecified iostream_category error

    I then "solved" the issue by including bitcoin#31318 in the sv2-ipc branch (#48), which for unrelated reasons drops that argument. Will bake a new release.

  5. Sjors commented on Nov 29, 2024

    @Sjors
    Sjors
    on Nov 29, 2024
    Owner

    @plebhash I'm still baking the binaries, but you should be able to test by building the new sv2-tp-0.1.11-ipc tag from source.

  6. plebhash commented on Nov 30, 2024

    @plebhash
    plebhash
    on Nov 30, 2024
    Author

    fixed on release sv2-tp-0.1.11-ipc

  7. plebhash
    closed this as completedon Nov 30, 2024

  8. maflcko commented on Dec 2, 2024

    @maflcko
    maflcko
    on Dec 2, 2024

    I narrowed it down to the scriptPubKey argument, because it still crashed when I dropped the options argument:

    2024-11-29T16:28:42.745177Z [ipc] {bitcoin-node-38256/b-capnp-loop-7165444} IPC server recv request  #5 Mining.createNewBlock$Params (scriptPubKey = "")
2024-11-29T16:28:42.745352Z [ipc] {bitcoin-node-38256/b-capnp-loop-7165444} IPC server unhandled exception: SpanReader::read(): end of data: unspecified iostream_category error

    I then "solved" the issue by including bitcoin#31318 in the sv2-ipc branch (#48), which for unrelated reasons drops that argument. Will bake a new release.

    Is there a reason why passing empty data leads to a crash? And why does bitcoin#31318 fix it, given that the argument is merely made an option, so the same crash could still be triggered, no?

  9. Sjors commented on Dec 2, 2024

    @Sjors
    Sjors
    on Dec 2, 2024
    Owner

    @maflcko it always crashes, even with a regular scriptPubKey.

    I haven't tried passing a scriptPubKey option through the interface. There's currently no use case for that. It's only used by unit tests that don't use the interface and by the RPC internally which also don't use it.

    Hence my suggestion in bitcoin#30437 (comment) that we have the demo util cover all methods (and arguments).

  10. maflcko commented on Dec 2, 2024

    @maflcko
    maflcko
    on Dec 2, 2024

    For reference, the traceback seems to be:

    ==47939==    by 0x11CC2F7: SpanReader::read(Span<std::byte>)
==47939==    by 0x9466E5: ParamsStream<SpanReader&, TransactionSerParams>::read(Span<std::byte>) (serialize.h:1134)
==47939==    by 0x98F78C: unsigned char ser_readdata8<ParamsStream<SpanReader&, TransactionSerParams> >(ParamsStream<SpanReader&, TransactionSerParams>&) (serialize.h:86)
==47939==    by 0x98F360: unsigned long ReadCompactSize<ParamsStream<SpanReader&, TransactionSerParams> >(ParamsStream<SpanReader&, TransactionSerParams>&, bool) (serialize.h:339)
==47939==    by 0x990D87: void Unserialize<ParamsStream<SpanReader&, TransactionSerParams>, 28u, unsigned char>(ParamsStream<SpanReader&, TransactionSerParams>&, prevector<28u, unsigned char, unsigned int, int>&) (serialize.h:825)
==47939==    by 0x990D2D: void UnserializeMany<ParamsStream<SpanReader&, TransactionSerParams>, prevector<28u, unsigned char, unsigned int, int>&>(ParamsStream<SpanReader&, TransactionSerParams>&, prevector<28u, unsigned char, unsigned int, int>&) (serialize.h:1000)
==47939==    by 0x990CDD: void ActionUnserialize::SerReadWriteMany<ParamsStream<SpanReader&, TransactionSerParams>, prevector<28u, unsigned char, unsigned int, int>&>(ParamsStream<SpanReader&, TransactionSerParams>&, prevector<28u, unsigned char, unsigned int, int>&) (serialize.h:1032)
==47939==    by 0x990C8D: void CScript::SerializationOps<ParamsStream<SpanReader&, TransactionSerParams>, CScript, ActionUnserialize>(CScript&, ParamsStream<SpanReader&, TransactionSerParams>&, ActionUnserialize) (script.h:465)
==47939==    by 0x990C2D: void CScript::Unser<ParamsStream<SpanReader&, TransactionSerParams> >(ParamsStream<SpanReader&, TransactionSerParams>&, CScript&) (script.h:465)
==47939==    by 0x990BDD: void CScript::Unserialize<ParamsStream<SpanReader&, TransactionSerParams> >(ParamsStream<SpanReader&, TransactionSerParams>&) (script.h:465)
==47939==    by 0xA0FE2F: auto decltype(auto) mp::CustomReadField<CScript, mp::StructField<mp::Accessor<mp::mining_fields::ScriptPubKey, 17>, ipc::capnp::messages::Mining::CreateNewBlockParams::Reader const>, mp::ReadDestEmplace<CScript, mp::PassField<mp::Accessor<mp::mining_fields::ScriptPubKey, 17>, CScript const&, mp::ServerInvokeContext<mp::ProxyServer<ipc::capnp::messages::Mining>, capnp::CallContext<ipc::capnp::messages::Mining::CreateNewBlockParams, ipc::capnp::messages::Mining::CreateNewBlockResults> >, mp::ServerField<1, mp::Accessor<mp::mining_fields::Options, 17>, mp::ServerRet<mp::Accessor<mp::mining_fields::Result, 18>, mp::ServerCall> > const&, mp::TypeList<node::BlockCreateOptions const&> >(mp::Priority<0>, mp::TypeList<CScript const&>, mp::ServerInvokeContext<mp::ProxyServer<ipc::capnp::messages::Mining>, capnp::CallContext<ipc::capnp::messages::Mining::CreateNewBlockParams, ipc::capnp::messages::Mining::CreateNewBlockResults> >&, mp::ServerField<1, mp::Accessor<mp::mining_fields::Options, 17>, mp::ServerRet<mp::Accessor<mp::mining_fields::Result, 18>, mp::ServerCall> > const&, mp::TypeList<node::BlockCreateOptions const&>&&)::{lambda((auto:1&&)...)#1}> >(mp::TypeList<CScript>, mp::Priority<1>, mp::InvokeContext&, mp::StructField<mp::Accessor<mp::mining_fields::ScriptPubKey, 17>, ipc::capnp::messages::Mining::CreateNewBlockParams::Reader const>&&, mp::ServerInvokeContext<mp::ProxyServer<ipc::capnp::messages::Mining>, capnp::CallContext<ipc::capnp::messages::Mining::CreateNewBlockParams, ipc::capnp::messages::Mining::CreateNewBlockResults> >&&) requires (Unserializable<CScript, DataStream>)&&(!(ipc::capnp::Deserializable<CScript>))::{lambda(auto:1&)#1}::operator()<CScript>(CScript&) const (common-types.h:79)

    This indicates that the error likely happens when (not) writing the compact size of the script/prevector.

  11. ryanofsky
    added 5 commits that reference this issue on Jan 27, 2025

    move: add mp/type-data.h

    5fdab5c

    move: add mp/type-data.h

    7d59b8d

    test: Add test for IPC serialization bug

    9983eb6

    test: Add test for IPC serialization bug

    4e0aa18
  12. janus
    added a commit that references this issue on Sep 1, 2025

    test: Add test for IPC serialization bug

    72a74ac
  13. Sjors
    added a commit that references this issue on May 12, 2026

    Squashed 'src/ipc/libmultiprocess/' changes from 3c69d12..27ada40809

    0dd3f5c
  14. Kino1994
    added a commit that references this issue on Jun 28, 2026

    test: Add test for IPC serialization bug

    d167d77
  15. BigcoinBGC
    added a commit that references this issue on Jun 30, 2026

    test: Add test for IPC serialization bug

    1ad73fa
  16. Kino1994
    added a commit that references this issue on Aug 19, 2026

    test: Add test for IPC serialization bug

    017a3a8
  17. xyzconstant
    added a commit that references this issue on Aug 27, 2026

    move: add mp/type-data.h

    5e50b97
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions