Worker thread shares same name with event loop thread creating confusion when inspecting in GDB

[Eunovo]

In the image obtained from running bitcoin-core's interface_ipc_mining test below, there are two "b-capnp-loop" threads: only one (Thread ID 11) is the actual worker thread calling createNewBlock().

This creates confusion for the developer trying to find the right thread to inspect.

I took a quick stab at this and tried to set the name of the newly created thread in ProxyServer<ThreadMap>::makeThread, but it didn't seem to work.

You can reproduce with this diff applied to bitcoin-core and using GDB to inspect the running threads.

diff --git a/src/interfaces/mining.h b/src/interfaces/mining.h
index f4c42e204a..bbef70196b 100644
--- a/src/interfaces/mining.h
+++ b/src/interfaces/mining.h
@@ -139,6 +139,13 @@ public:
      */
     virtual void interrupt() = 0;
 
+    /**
+     * Sets the debug mining flag.
+     *
+     * @param[in] debug_mining whether to enable debug mining mode
+     */
+    virtual void setDebugMining(bool debug_mining) = 0;
+
     /**
      * Checks if a given block is valid.
      *
diff --git a/src/ipc/capnp/mining.capnp b/src/ipc/capnp/mining.capnp
index 64cad4d49f..38a1758f61 100644
--- a/src/ipc/capnp/mining.capnp
+++ b/src/ipc/capnp/mining.capnp
@@ -25,6 +25,7 @@ interface Mining $Proxy.wrap("interfaces::Mining") {
     createNewBlock @4 (context :Proxy.Context, options: BlockCreateOptions, cooldown: Bool = true) -> (result: BlockTemplate);
     checkBlock @5 (context :Proxy.Context, block: Data, options: BlockCheckOptions) -> (reason: Text, debug: Text, result: Bool);
     interrupt @6 () -> ();
+    setDebugMining @7 (debugMining: Bool) -> ();
 }
 
 interface BlockTemplate $Proxy.wrap("interfaces::BlockTemplate") {
diff --git a/src/node/interfaces.cpp b/src/node/interfaces.cpp
index 84fd5bb794..e83e7ea003 100644
--- a/src/node/interfaces.cpp
+++ b/src/node/interfaces.cpp
@@ -959,6 +959,9 @@ public:
 
     std::unique_ptr<BlockTemplate> createNewBlock(const BlockCreateOptions& options, bool cooldown) override
     {
+        if (m_debug_mining) {
+            while (true) {} //DEBUG
+        }
         // Reject too-small values instead of clamping so callers don't silently
         // end up mining with different options than requested. This matches the
         // behavior of the `-blockreservedweight` startup option, which rejects
@@ -999,6 +1002,11 @@ public:
         InterruptWait(notifications(), m_interrupt_mining);
     }
 
+    void setDebugMining(bool debug_mining) override
+    {
+        m_debug_mining = debug_mining;
+    }
+
     bool checkBlock(const CBlock& block, const node::BlockCheckOptions& options, std::string& reason, std::string& debug) override
     {
         LOCK(chainman().GetMutex());
@@ -1013,6 +1021,7 @@ public:
     KernelNotifications& notifications() { return *Assert(m_node.notifications); }
     // Treat as if guarded by notifications().m_tip_block_mutex
     bool m_interrupt_mining{false};
+    bool m_debug_mining{false};
     NodeContext& m_node;
 };
 } // namespace
diff --git a/test/functional/test_framework/ipc_util.py b/test/functional/test_framework/ipc_util.py
index 11497463eb..1469294b63 100644
--- a/test/functional/test_framework/ipc_util.py
+++ b/test/functional/test_framework/ipc_util.py
@@ -108,6 +108,8 @@ async def make_capnp_init_ctx(self):
 
 async def mining_create_block_template(mining, stack, ctx, opts):
     """Call mining.createNewBlock() and return template, then call template.destroy() when stack exits."""
+    await mining.setDebugMining(True)  # Block createNewBlock() infinitely
+    import pdb; pdb.set_trace()
     response = await mining.createNewBlock(ctx, opts)
     if not response._has("result"):
         return None

[ryanofsky]

I took a quick stab at this and tried to set the name of the newly created thread in ProxyServer<ThreadMap>::makeThread, but it didn't seem to work.

That's surprising. But one problem might be that the thread name passed passed to the OS is too long. I believe the name passed includes the exe name + thread name from the calling process. Might make sense to split it up or add truncation if that is the problem

[Eunovo]

I believe the name passed includes the exe name + thread name from the calling process. Might make sense to split it up or add truncation if that is the problem

I had the same thought, and I believe I tried shorter names as well, but the name of the worker thread remained unchanged. I can double-check this later to confirm.