Client becomes unresponsive when finishing large recheck

[PAI5REECHO]

qBittorrent & operating system versions

qBittorrent: v4.4.1 (64-bit) Operating System: NixOS 21.11 (kernel 5.16.11) Qt: 5.15.3 Libtorrent: 2.0.5.0

What is the problem?

After a large torrent (~200GB) finishes rechecking the client completely freezes and the UI becomes unresponsive.

Steps to reproduce

1. Complete downloading a large torrent
2. Remove the torrent from the client
3. Add the same torrent without starting it
4. Recheck the torrent
5. At 100% recheck completion the client freezes

Additional context

I went ahead and attached a profiler during the period of time when the client became unresponsive (sudo perf record -p $(pidof qbittorrent) --call-graph dwarf) Here's a breakdown of symbols consuming more than 1% of execution time (from perf report):

+   86.98%    86.74%  ..qbittorrent-w  libcrypto.so.1.1               [.] sha256_block_data_order_avx2
+   14.39%     1.01%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] libtorrent::merkle_root_scratch
+   14.16%     0.00%  ..qbittorrent-w  libc-2.33.so                   [.] __GI___clone (inlined)
+   14.16%     0.00%  ..qbittorrent-w  libpthread-2.33.so             [.] start_thread
+   14.16%     0.00%  ..qbittorrent-w  libstdc++.so.6.0.28            [.] 0x00007fdcf8138c4f
+   14.15%     0.00%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] std::thread::_State_impl<std::thread::_Invoker<std::tuple<libtorrent::session::start(libtorrent::flags::bitfield_flag
+   14.15%     0.00%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] boost::asio::detail::scheduler::run
+   14.15%     0.00%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] boost::asio::detail::executor_op<boost::asio::detail::binder0<libtorrent::torrent_handle::sync_call_ret<std::shared_p
+   14.15%     0.00%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] libtorrent::torrent::get_torrent_copy_with_hashes
+   14.15%     0.00%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] libtorrent::aux::merkle_tree::get_piece_layer
+    7.30%     4.75%  ..qbittorrent-w  libcrypto.so.1.1               [.] SHA256_Update
+    6.71%     0.45%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] libtorrent::lcrypto::hasher256::update
+    6.07%     0.13%  ..qbittorrent-w  libtorrent-rasterbar.so.2.0.5  [.] libtorrent::lcrypto::hasher256::final
+    5.95%     3.04%  ..qbittorrent-w  libcrypto.so.1.1               [.] SHA256_Final
+    1.38%     1.38%  ..qbittorrent-w  libcrypto.so.1.1               [.] OPENSSL_cleanse

Log(s) & preferences file(s)

No response

[ghost]

What kind of torrent is it? (V1/V2/Hybrid)

[PAI5REECHO]

Under the General > Information tab it lists both an Info Hash v1 & Info Hash v2 so I'm assuming it's a hybrid torrent

[ghost]

How much RAM do you have and how much is in use when qBt freezes.

[PAI5REECHO]

I was going to let the recheck run to 99.5% and then close the client and reopen it with a profiler attached to get data about what happens to the client when it freezes but the torrent disappears with the log message - Unable to resume torrent '<info hash>'. (#16607 & #16420) when reopening the client with the partially rechecked torrent any time the recheck progress is more than ~10%.

[ghost]

Is it possible to share the fastresume file that qBt fails to resume?

[glassez]

@PAI5REECHO Do you use Copy .torrent files for finished downloads to: option?