Force stopping all threads and libevent timers when test completes or Ctrl+C is pressed

[fcostaoliveira]

Note

Medium Risk
Touches shutdown/cleanup and libevent timer/bufferevent lifecycle across threads; incorrect teardown ordering could cause leaks, hangs, or use-after-free during stop conditions.

Overview
Ensures benchmarks shut down promptly by adding a new forceful stop path that tears down all libevent resources and pending work instead of waiting for normal completion.

This introduces force_stop() on client, client_group, and shard_connection to delete timers, disable/free bufferevents, and drain pending requests; m_pending_resp is made atomic to avoid benign races when polled from the main thread. The main runner now uses force_stop() on Ctrl+C and when --test-time elapses, printing how many threads are being stopped and waiting until they report finished; the interrupt message assertion in tests_oss_simple_flow.py is updated accordingly.

^{Written by Cursor Bugbot for commit 871b6bc. This will update automatically on new commits. Configure here.}

[cursor]

Race condition between force_stop and event loop callbacks

High Severity

client_group::force_stop() frees resources (via shard_connection::force_stop()) while the worker thread's event loop may still be executing callbacks that use those resources. The event_base_loopbreak() is called AFTER resources are freed at lines 752-755, but the worker thread could be inside a callback like handle_timer_event() accessing m_event_timer, m_bev, etc. that are being freed. Since libevent thread-safety isn't enabled (no evthread_use_pthreads() call), this creates a use-after-free race condition.

Additional Locations (1)

• shard_connection.cpp#L376-L417

 

[cursor]

Duplicated thread waiting loop code

Low Severity

The waiting loop that polls active_threads and prints status messages is duplicated identically in two places: once for Ctrl+C handling and once for test-time completion. This creates maintenance burden since any future bug fix or enhancement would need to be applied to both locations, risking inconsistent behavior if one is missed.

Additional Locations (1)

• memtier_benchmark.cpp#L1808-L1820

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

Unused variable m_stop_requested is set but never read

Low Severity

The m_stop_requested atomic variable is declared in client.h, initialized in the constructor, and set to true in force_stop(), but it's never read anywhere. The comment states "this will cause the run() loop to exit" but run() simply calls event_base_dispatch(m_base) without checking this flag. The actual mechanism that stops the loop is event_base_loopbreak() called later. This is dead code that should be removed.

Additional Locations (1)

• client.h#L212-L213