[all-commits] [llvm/llvm-project] 6a47b1: Don't crash reloading a corefile saved from a live...

[Yao Qi via All-commits]

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

  Changed paths:
    M lldb/source/Plugins/InstrumentationRuntime/BoundsSafety/InstrumentationRuntimeBoundsSafety.cpp
    A lldb/test/API/functionalities/process_save_core_minidump_reload_crash/Makefile
    A lldb/test/API/functionalities/process_save_core_minidump_reload_crash/TestMinidumpReloadCrash.py
    A lldb/test/API/functionalities/process_save_core_minidump_reload_crash/main.c

  Log Message:
  -----------
  Don't crash reloading a corefile saved from a live process (#224324)

Saving a live process as a corefile and reloading it can abort lldb
itself:

```
$ cat main.c
int main(int argc, char **argv) { return argc; }
$ cc -g -O0 -o a.out main.c
$ lldb ./a.out -o 'b main' -o run \
    -o 'process save-core --plugin-name=minidump --style=stack core.dmp' \
    -o quit
$ lldb -c core.dmp
(lldb) target create --core "core.dmp"
...
Assertion failed: (0 && "breakpoint has no resolved locations"), function Activate, file InstrumentationRuntimeBoundsSafety.cpp, line 467.
```

`InstrumentationRuntimeBoundsSafety::CheckIfRuntimeIsValid` only checks
whether a loaded module exports two soft-trap symbol names
(`__bounds_safety_soft_trap`, `__bounds_safety_soft_trap_s`), not
whether
the process actually uses BoundsSafety.
`InstrumentationRuntimeBoundsSafety::Activate` runs for any process,
sets
a breakpoint on those two names, and, until this change, asserted if
that
breakpoint failed to resolve to any location.

`ProcessMinidump::ReadModuleList` is what makes the breakpoint fail to
resolve.  For each module in the minidump, it calls
`Target::GetOrCreateModule(module_spec, /*notify=*/true, ...)`
(`ProcessMinidump.cpp`); that call synchronously triggers
`ModuleList::NotifyModuleAdded`, which runs `Target::ModulesDidLoad` and
from there `Process::ModulesDidLoad`  calls
`InstrumentationRuntimeBoundsSafety::Activate`.  Only after that returns
does the same loop iteration reach `module_sp->SetLoadAddress(...)` and
registers the module's sections at a load address, and address can be
resolved correct. However, before reaching to this point, the breakpoint
fails to resolve because that module still has no load address at all,
and trigger assert.  This is an ordering problem in the reload.

Reloading the same live process from a mach-o corefile does not hit
this,
for two different reasons depending on `--style`.  A `--style=stack`
corefile does not load `libsystem_sanitizers.dylib` at all (confirmed
with `target modules list`: only the executable and `dyld` are present),
so `CheckIfRuntimeIsValid` never finds the symbols and `Activate` never
runs.  A `--style=full` corefile does load it, and resolves the same
breakpoint correctly, because `ObjectFileMachO::LoadCoreFileImages`
addresses every image in the batch first and only calls
`Target::ModulesDidLoad` once, after every module already has a load
address, instead of notifying and addressing one module at a time.

Added
`lldb/test/API/functionalities/process_save_core_minidump_reload_crash`,
which builds a plain program using no BoundsSafety feature, saves a live
process as a minidump, and reloads it into a fresh target.  Before this
change that reload aborted the `lldb` process; it now loads
successfully.

Assited-by: claude



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