Skip to content

Fix stale AgentGroup TLS access after bthread migration - #3522

Open
bobhan1 wants to merge 1 commit into
apache:masterfrom
bobhan1:fix-3520-agent-group-tls-access
Open

Fix stale AgentGroup TLS access after bthread migration#3522
bobhan1 wants to merge 1 commit into
apache:masterfrom
bobhan1:fix-3520-agent-group-tls-access

Conversation

@bobhan1

@bobhan1 bobhan1 commented Sep 4, 2026

Copy link
Copy Markdown

What problem does this PR solve?

Issue Number: resolve #3520

Problem Summary:

bvar::detail::AgentGroup directly accesses the raw _s_tls_blocks thread-local variable from inline functions. When a bthread suspends and resumes on another pthread, Clang may reuse the TLS address resolved for the previous pthread. This can make bvar access another pthread's agent vector and race with its initialization or resize.

What is changed and the side effects?

Changed:

  • Declare _s_tls_blocks with the existing static-member volatile TLS accessor mechanism.
  • Resolve the current pthread's TLS block vector once in each AgentGroup operation and consistently use that pointer.
  • Route TLS initialization and cleanup writes through the existing setter accessor.

Side effects:

  • Performance effects: On compiler targets where volatile TLS access is enabled, AgentGroup operations use the existing noinline TLS accessor to prevent the TLS address from being retained across a bthread suspend point. Other targets retain direct TLS access through the existing macros.
  • Breaking backward compatibility: None.

Check List:

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The fix targets a bthread migration/TLS-staleness scenario but there’s no accompanying regression test exercising bthread suspend/resume migration behavior to prevent future regressions.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Fixes a bthread-migration correctness bug in bvar::detail::AgentGroup where Clang may retain a stale TLS reference across a suspend/resume on a different pthread, potentially causing cross-pthread agent-vector access and crashes.

Changes:

  • Switch _s_tls_blocks to the existing volatile-TLS accessor pattern (STATIC_MEMBER_BAIDU_VOLATILE_THREAD_LOCAL, BAIDU_GET/SET_VOLATILE_THREAD_LOCAL).
  • In each AgentGroup operation, resolve the current pthread’s TLS block-vector once and consistently use that local pointer.
  • Route TLS initialization/cleanup writes through the existing setter accessor.
File summaries
File Description
src/bvar/detail/agent_group.h Reworks _s_tls_blocks access to use volatile-TLS accessors and per-operation resolution to avoid stale TLS across bthread migration.
Review details
  • Files reviewed: 1/1 changed files
  • Comments generated: 1
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +116 to +120
std::vector<ThreadBlock*>* tls_blocks =
BAIDU_GET_VOLATILE_THREAD_LOCAL(_s_tls_blocks);
if (tls_blocks) {
const size_t block_id = (size_t)id / ELEMENTS_PER_BLOCK;
if (block_id < _s_tls_blocks->size()) {
ThreadBlock* const tb = (*_s_tls_blocks)[block_id];
if (block_id < tls_blocks->size()) {
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bvar] AgentGroup may use a stale _s_tls_blocks address after bthread migration under Clang

2 participants