bitcoin/bitcoin#32345 fixes different bitcoin-node crashes during shutdown when IPC connections are not terminated cleanly (either disconnected or unresponsive), letting the node shut down cleanly without blocking in all cases.
But testing bitcoin/bitcoin#32345 in combination with bitcoin/bitcoin#29409 and a custom client that connects and disconnects in a loop @darosior found another crash that seems to happen when a client disconnects in the middle of an IPC call apparently because an assumption in the ~Connection destructor is violated:
|
// Shut down RPC system first, since this will garbage collect Server |
|
// objects that were not freed before the connection was closed, some of |
|
// which may call addAsyncCleanup and add more cleanup callbacks which can |
|
// run below. |
|
m_rpc_system.reset(); |
that cap'n proto will garbage collect server objects right away when the canp::RpcSystem is destroyed.
Apparently this does not happen if an asynchronous call is currently in progress.
I was able to reproduce the problem with ryanofsky/bitcoin@87b2ae6 (tag) and I think the fix will probably require the Connection refcounting described #176 (comment) that I started implementing but abandoned later #176 (comment) because it didn't seem necessary.
bitcoin/bitcoin#32345 fixes different bitcoin-node crashes during shutdown when IPC connections are not terminated cleanly (either disconnected or unresponsive), letting the node shut down cleanly without blocking in all cases.
But testing bitcoin/bitcoin#32345 in combination with bitcoin/bitcoin#29409 and a custom client that connects and disconnects in a loop @darosior found another crash that seems to happen when a client disconnects in the middle of an IPC call apparently because an assumption in the
~Connectiondestructor is violated:libmultiprocess/src/mp/proxy.cpp
Lines 53 to 57 in 27c7e8e
that cap'n proto will garbage collect server objects right away when the
canp::RpcSystemis destroyed.Apparently this does not happen if an asynchronous call is currently in progress.
I was able to reproduce the problem with ryanofsky/bitcoin@87b2ae6 (tag) and I think the fix will probably require the Connection refcounting described #176 (comment) that I started implementing but abandoned later #176 (comment) because it didn't seem necessary.