[llvm-bugs] [Bug 48118] New: A null pointer dereference error in DWARFLinker::loadClangModule

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48118

            Bug ID: 48118
           Summary: A null pointer dereference error in
                    DWARFLinker::loadClangModule
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Linker
          Assignee: unassignedbugs at nondot.org
          Reporter: alansnape3058 at gmail.com
                CC: llvm-bugs at lists.llvm.org

According to the bug reports of my clang static analyzer fork, in function
`DWARFLinker::loadClangModule`, the local variable `Unit` may not be
initialized and will trigger a null pointer dereference problem when
dereferencing it.

1. call function DWARFLinker::loadClangModule
llvm/lib/DWARFLinker/DWARFLinker.cpp
2012 Error DWARFLinker::loadClangModule(

2. create local variable std::unique_ptr<CompileUnit> Unit
llvm/lib/DWARFLinker/DWARFLinker.cpp
2033   std::unique_ptr<CompileUnit> Unit;

3. skip the initialization of Unit in the loop from 2035 to 2080
llvm/lib/DWARFLinker/DWARFLinker.cpp
2035   for (const auto &CU : ErrOrObj->Dwarf->compile_units()) {
2036     updateDwarfVersion(CU->getVersion());
2037     // Recursively get all modules imported by this one.
2038     auto CUDie = CU->getUnitDIE(false);
2039     if (!CUDie)
2040       continue;
2041     if (!registerModuleReference(
2042             CUDie, *CU, File, StringPool, UniquingStringPool, ODRContexts,
2043             ModulesEndOffset, UnitID, IsLittleEndian, Indent, Quiet)) {
2044       if (Unit) {
2045         std::string Err =
2046             (Filename +
2047              ": Clang modules are expected to have exactly 1 compile
unit.\n")
2048                 .str();
2049         reportError(Err, File);
2050         return make_error<StringError>(Err, inconvertibleErrorCode());
2051       }
2052       // FIXME: Until PR27449
(https://llvm.org/bugs/show_bug.cgi?id=27449) is
2053       // fixed in clang, only warn about DWO_id mismatches in verbose
mode.
2054       // ASTFileSignatures will change randomly when a module is rebuilt.
2055       uint64_t PCMDwoId = getDwoId(CUDie, *CU);
2056       if (PCMDwoId != DwoId) {
2057         if (!Quiet && Options.Verbose)
2058           reportWarning(
2059               Twine("hash mismatch: this object file was built against a "
2060                     "different version of the module ") +
2061                   Filename,
2062               File);
2063         // Update the cache entry with the DwoId of the module loaded from
disk.
2064         ClangModules[Filename] = PCMDwoId;
2065       }
2066

   Assume the initialization of the variable `Unit` is not executed. {{{

2067       // Add this module.
2068       Unit = std::make_unique<CompileUnit>(*CU, UnitID++, !Options.NoODR,
2069                                            ModuleName);

   }}}

2070       Unit->setHasInterestingContent();
2071       analyzeContextInfo(CUDie, 0, *Unit, &ODRContexts.getRoot(),
2072                          UniquingStringPool, ODRContexts,
ModulesEndOffset,
2073                          Options.ParseableSwiftInterfaces,
2074                          [&](const Twine &Warning, const DWARFDie &DIE) {
2075                            reportWarning(Warning, File, &DIE);
2076                          });
2077       // Keep everything.
2078       Unit->markEverythingAsKept();
2079     }
2080   }


3. dereference on null smart pointer
llvm/lib/DWARFLinker/DWARFLinker.cpp
2081   if (!Unit->getOrigUnit().getUnitDIE().hasChildren())

Although the problem will not be triggered by the path presented, the problem
still worth noting.

See the HTML report for more details:
http://lcs.ios.ac.cn/~maxt/SPelton/reports/llvm/report-dc3dc4.html#EndPath

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201109/bbd0e9b6/attachment-0001.html>