Tracer caught signal 11 if asan is enabled

[BusyJay]

Describe the bug
Tracer caught signal 11: addr=0x7f57067db000 pc=0x7f572d0c3010 sp=0x7f5721313d10
==140089==LeakSanitizer has encountered a fatal error.
==140089==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==140089==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

To Reproduce
None yet.

Expected behavior
It works.

Versions
OS:
Compiler:
brpc:
protobuf:

Additional context/screenshots

Analysis from AI:

新版 brpc 在 BUTIL_USE_ASAN 路径下，对每段 bthread 协程栈（small/normal/large，1MB ~ 8MB）调用 __asan_poison_memory_region，把整段栈在 ASan shadow memory 里标为 unaddressable：

BUTIL_FORCE_INLINE void ASanPoisonMemoryRegion(const StackStorage& storage) {
    if (NULL == storage.bottom) return;
    BUTIL_ASAN_POISON_MEMORY_REGION(
        (char*)storage.bottom - storage.stacksize, storage.stacksize);
}

调用点：

• stack_inl.h:136 — Wrapper 构造时 poison
• stack_inl.h:158 — return_stack 把协程栈归还 ObjectPool 时 poison

每个 worker pthread 持有数十段协程栈，进程内累积 GB 级 poisoned mmap 区域。

进程退出时触发链路：

__cxa_finalize
  → __lsan::DoLeakCheck()
    → StopTheWorld
      → ListThreads (getdents /proc/<pid>/task)
      → GetThreadRangesLocked (读 AsanThread 的 stack/TLS 范围)
      → ScanRangeForPointers (扫描每个线程栈作为 root set)
        → 触碰被 brpc poison 的协程栈区域
          → ASan shadow check 内部异常
            → SIGSEGV
              → mysqld abnormal exit
                → shutdown_report fail

[shui8023]

问题

在 ASan 构建（-fsanitize=address）下，启用 LSan（detect_leaks=1，ASan 默认）的 brpc 进程在退出阶段稳定崩溃：

Tracer caught signal 11: addr=0x... pc=0x... sp=0x...
==XXX==LeakSanitizer has encountered a fatal error.
==XXX==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

崩溃发生在 LSan tracer 子进程内的 __lsan::ProcessThread → ScanRangeForPointers 路径——tracer raw deref 到一个 PROT_NONE guard page 时 SIGSEGV，由于 tracer 与父进程 clone(CLONE_VM) 共享地址空间，整个 brpc 进程被 kernel 同步杀死。

根因（最终确认）

brpc task_group.cpp 在 BUTIL_USE_ASAN_MAIN_STACK 启用时把 worker pthread 真栈注册到 _main_stack->storage，两个字段中 storage.bottom 的填值与 brpc 自身约定的语义相反：

// brpc/src/bthread/task_group.cpp:325-329 (BUG)
#ifdef BUTIL_USE_ASAN_MAIN_STACK
    stk->storage.bottom = stack_addr;          // ← BUG
    stk->storage.stacksize = stack_size;
#endif

• stack_addr 来自 pthread_attr_getstack，POSIX 语义是 stack 的最低地址（栈底 / lowest addressable byte）
• 但 brpc 自己的 StackStorage::bottom 在协程栈代码里被定义为 stack 的最高地址（栈顶）：

// brpc/src/bthread/stack.cpp:128 (协程栈，作为参考约定)
s->bottom = (char*)mem + memsize;   // 高端地址 = 栈顶

• StartSwitchFiber 依赖这个约定计算传给 ASan 的 stack range：

// brpc/src/bthread/stack_inl.h:64
void* asan_stack_bottom = (char*)storage.bottom - storage.stacksize;  // 高端 - size = 低端
__sanitizer_start_switch_fiber(saved, asan_stack_bottom, storage.stacksize);

这个公式对协程栈正确（storage.bottom 是高端），但对 main_stack 整体错位 stack_size（默认 8 MB），把 ASan 视角下的 stack range 推到 worker pthread 真栈之前 8 MB 的虚拟地址范围内——那是别的线程的栈片段、协程栈群、和大量 PROT_NONE guard page 所在区域。

LSan StopTheWorld 通过 GetThreadRangesLocked 拿到 AsanThread::stack_bottom_/stack_top_（被 fiber switcher 错位写入），命中 sp 不在 stack range 分支后扫整段 8 MB，撞到中间 PROT_NONE guard 页时 SIGSEGV。

[chenBright]

brpc task_group.cpp 在 BUTIL_USE_ASAN_MAIN_STACK 启用时把 worker pthread 真栈注册到 _main_stack->storage，两个字段中 storage.bottom 的填值与 brpc 自身约定的语义相反

This issue has been fixed in #3298 .