Skip to content

Check for null oso SymbolFile in SymbolFileDwarfDebugMap::ResolveSymbolContext #89324

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 18, 2024

Conversation

jimingham
Copy link
Collaborator

The couple other places that use the oso module's SymbolFile, they check that it's non-null, so this is just an oversight in ResolveSymbolContext.

I didn't add a test for this (but did add a log message for the error case) because I can't see how this would actually happen. The .o file had to have valid enough DWARF that the linker's parser could handle it or it would not be in the debug map. If you delete the .o file, we just leave that entry out of the debug map. If you strip it or otherwise mess with it, we'll notice the changed mod time and refuse to read it...

This was based on a report from the field, and we don't have access to the project. But if the logging tells me how this happened I can come back and add a test with that example.

…olContext.

The couple other places that use the oso module's SymbolFile, they check that
it's non-null, so this is just an oversight in ResolveSymbolContext.

I didn't add a test for this (but did add a log message for the error case)
because I can't see how this would actually happen.  The .o file had to have
valid enough DWARF that the linker's parser could handle it or it would not be
in the debug map.  If you delete the .o file, we just leave that entry out of
the debug map.  If you strip it or otherwise mess with it, we'll notice the
changed mod time and refuse to read it...

This was based on a report from the field, and we don't have access to the
project.  But if the logging tells me how this happened I can come back and add a test with
that example.
@jimingham jimingham requested a review from bulbazord April 18, 2024 22:09
@jimingham jimingham requested a review from JDevlieghere as a code owner April 18, 2024 22:09
@llvmbot llvmbot added the lldb label Apr 18, 2024
@llvmbot
Copy link
Member

llvmbot commented Apr 18, 2024

@llvm/pr-subscribers-lldb

Author: None (jimingham)

Changes

The couple other places that use the oso module's SymbolFile, they check that it's non-null, so this is just an oversight in ResolveSymbolContext.

I didn't add a test for this (but did add a log message for the error case) because I can't see how this would actually happen. The .o file had to have valid enough DWARF that the linker's parser could handle it or it would not be in the debug map. If you delete the .o file, we just leave that entry out of the debug map. If you strip it or otherwise mess with it, we'll notice the changed mod time and refuse to read it...

This was based on a report from the field, and we don't have access to the project. But if the logging tells me how this happened I can come back and add a test with that example.


Full diff: https://github.com/llvm/llvm-project/pull/89324.diff

1 Files Affected:

  • (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp (+12-3)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
index 1de585832e3216..d6560e399e4fc4 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -848,9 +848,18 @@ SymbolFileDWARFDebugMap::ResolveSymbolContext(const Address &exe_so_addr,
                 debug_map_entry->data.GetOSOFileAddress();
             Address oso_so_addr;
             if (oso_module->ResolveFileAddress(oso_file_addr, oso_so_addr)) {
-              resolved_flags |=
-                  oso_module->GetSymbolFile()->ResolveSymbolContext(
-                      oso_so_addr, resolve_scope, sc);
+              SymbolFile *sym_file = oso_module->GetSymbolFile();
+              if (sym_file) {
+                resolved_flags |= sym_file->ResolveSymbolContext(oso_so_addr, 
+                    resolve_scope, sc);
+              } else {
+                ObjectFile *obj_file = GetObjectFile();
+                LLDB_LOG(GetLog(DWARFLog::DebugMap),
+                         "Failed to get symfile for OSO: {0} in module: {1}", 
+                         oso_module->GetFileSpec(), 
+                         obj_file ? obj_file->GetFileSpec() : 
+                             FileSpec("unknown"));
+              }
             }
           }
         }

Copy link

github-actions bot commented Apr 18, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

oso_module->GetSymbolFile()->ResolveSymbolContext(
oso_so_addr, resolve_scope, sc);
SymbolFile *sym_file = oso_module->GetSymbolFile();
if (sym_file) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: if (SymbolFile *sym_file = oso_module->GetSymbolFile()) {

Copy link
Member

@JDevlieghere JDevlieghere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with Alex' suggestion and the code formatted.

@jimingham jimingham merged commit 6b38936 into llvm:main Apr 18, 2024
@jimingham jimingham deleted the check-symbol-file branch April 18, 2024 23:18
jimingham added a commit to jimingham/from-apple-llvm-project that referenced this pull request Apr 19, 2024
…olContext (llvm#89324)

The couple other places that use the oso module's SymbolFile, they check
that it's non-null, so this is just an oversight in
ResolveSymbolContext.

I didn't add a test for this (but did add a log message for the error
case) because I can't see how this would actually happen. The .o file
had to have valid enough DWARF that the linker's parser could handle it
or it would not be in the debug map. If you delete the .o file, we just
leave that entry out of the debug map. If you strip it or otherwise mess
with it, we'll notice the changed mod time and refuse to read it...

This was based on a report from the field, and we don't have access to
the project. But if the logging tells me how this happened I can come
back and add a test with that example.

(cherry picked from commit 6b38936)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants