[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