[all-commits] [llvm/llvm-project] d01d1d: [lldb][test] Run TestExpeditedStackMemory's call c...

[Yao Qi via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d01d1da97442654ca837893d46c4b50463473687
      https://github.com/llvm/llvm-project/commit/d01d1da97442654ca837893d46c4b50463473687
  Author: Yao Qi <yao_qi at apple.com>
  Date:   2026-09-24 (Thu, 24 Sep 2026)

  Changed paths:
    M lldb/test/API/macosx/expedited-stack-memory/main.c

  Log Message:
  -----------
  [lldb][test] Run TestExpeditedStackMemory's call chain on a new thread (#226248)

`test_memory_reads_when_examining_all_frames_locals` fails on some
machine,
```
AssertionError: 0 not greater than 0 : expected stack memory reads while examining deeper frames' stack-resident locals.
memory reads while examining locals: stack=0 heap=1 other=1 (total=2)
```
In the packet log of one run, lldb stops at dyld's `lldb_image_notifier`
before `main` runs, and reads image info array is on the main thread's
stack,
and lldb reads one cache line (512 bytes) in one go.

Due to the new feature #223417, debugserver keeps this range as a recent
read and sends it again at later stops. At the breakpoint in `func_e`,
`jThreadsInfo` also sends the recent reads, which cover the call chain's
stack by accident, so lldb reads every local on every frame from its
cache
and the walk sends no stack read.  That is why test failed.

Run the call chain on a new thread. No stop before the breakpoint reads
that thread's stack, so a recent read cannot cover the frames under
test.

Assisted-by: claude



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications