-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
Conversation
…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.
@llvm/pr-subscribers-lldb Author: None (jimingham) ChangesThe 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:
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"));
+ }
}
}
}
|
✅ 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) { |
There was a problem hiding this comment.
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()) {
There was a problem hiding this 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.
…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)
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.