[llvm] [llvm-symbolizer] Recognize AIX big archive (PR #150401)
via llvm-commits
llvm-commits at lists.llvm.org
Sun Sep 28 22:49:37 PDT 2025
================
@@ -716,9 +811,9 @@ LLVMSymbolizer::getOrCreateModuleInfo(StringRef ModuleName) {
createModuleInfo(Objects.first, std::move(Context), ModuleName);
if (ModuleOrErr) {
auto I = Modules.find(ModuleName);
- BinaryForPath.find(BinaryName)->second.pushEvictor([this, I]() {
- Modules.erase(I);
- });
+ auto BinIter = BinaryForPath.find(BinaryName);
+ if (BinIter != BinaryForPath.end())
----------------
midhuncodes7 wrote:
For a plain object file (t.o) the `ModuleName` is "t.o" and `BinaryForPath` also stores an entry keyed by "t.o". `BinaryForPath.find(BinaryName) `succeeds and so is `->second.pushEvictor(...)`.
For an archive member "(t.a(t.o))", `loadOrGetBinary` (and `BinaryForPath.emplace`) is called with the archive path "t.a" (not the "(t.o)" suffix).
But `getOrCreateModuleInfo` still uses `ModuleName` (which is the full "t.a(t.o)") as `BinaryName` when it later does `BinaryForPath.find(BinaryName)`.
That find("t.a(t.o)") returns `end() `(no such key) and when `->second` on that `end()` result — undefined behavior that manifests as a segfault during destructor call.
Updating `BinaryForPath` as "t.a(t.o)" will result in invalid path.
Updating `BinaryName` as "t.a" will result in breaking per-member resolution
Hope this helps
https://github.com/llvm/llvm-project/pull/150401
More information about the llvm-commits
mailing list