From 39f000b3948e64a38b14b1d358ced1b2d1f44bf3 Mon Sep 17 00:00:00 2001 From: moneromooo-monero Date: Thu, 14 Mar 2019 16:54:03 +0000 Subject: [PATCH] miner: fix possible exit crash due to race in stop If a thread asks to stop the miner, m_stop will be set, and that thread will wait to join. If the main thread is exiting at that time, it will ask the miner to stop, but the miner will claim it's not mining and early out since m_stop is set. This will cause the database and other things to get shutdown. If the miner happens to find a block at that time, it will try to call core, and crash. Instead, lock and check whether any threads are currently in m_threads, since they'll only be cleared once the threads are joined. Moreover, since we lock, the second thread will have to wait for the first one to have finished. Calling join twice on a thread seems fine as per pthread_join(3). --- src/cryptonote_basic/miner.cpp | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/cryptonote_basic/miner.cpp b/src/cryptonote_basic/miner.cpp index 3a51c6ea4..1e211d00b 100644 --- a/src/cryptonote_basic/miner.cpp +++ b/src/cryptonote_basic/miner.cpp @@ -432,14 +432,15 @@ namespace cryptonote { MTRACE("Miner has received stop signal"); - if (!is_mining()) + CRITICAL_REGION_LOCAL(m_threads_lock); + bool mining = !m_threads.empty(); + if (!mining) { MTRACE("Not mining - nothing to stop" ); return true; } send_stop_signal(); - CRITICAL_REGION_LOCAL(m_threads_lock); // In case background mining was active and the miner threads are waiting // on the background miner to signal start.