llvmbot
commented
2 years ago @llvm/issue-subscribers-bug
Open dmlary opened 2 years ago
llvmbot
commented
2 years ago @llvm/issue-subscribers-bug
llvmbot
commented
2 years ago @llvm/issue-subscribers-lldb
JDevlieghere
commented
2 years ago We're actually crashing in the Address copy constructor. llvm::sys::PrintStackTrace is what prints the little stack trace in the console and gets called from the signal handler. It appears like we're crashing when copy-constructing the m_section_wp weak pointer.
dmlary
commented
2 years ago You're right! I should have pieced that together.
For a little more background, this is happening during some dll lazy-loading function stubs. They work, but they do perform some questionable actions on the stack to allow the original function call arguments to get passed to the dll function once the dll has been opened and the address looked up.
Looking at the coredump (with C, not C++ experience), this is the only frame in the backtrace I see anything vaguely intersting, sc.function == nullptr going into GetAddressRange():
frame #4: 0x00007f554883fc98 liblldb.so.13`CommandObjectThreadUntil::DoExecute(this=0x00000000019f7eb0, command=0x00007fffdfdf9be0, result=0x00007fffdfdf9f60) at CommandObjectThread.cpp:972
969 std::vector<addr_t> address_list;
970
971 // Find the beginning & end index of the
-> 972 AddressRange fun_addr_range = sc.function->GetAddressRange();
973 Address fun_start_addr = fun_addr_range.GetBaseAddress();
974 line_table->FindLineEntryByAddress(fun_start_addr, function_start,
975 &index_ptr);
(lldb) p sc
(lldb_private::SymbolContext) $0 = {
target_sp = std::__shared_ptr<lldb_private::Target, 4>::element_type @ 0x0000000001ad2c10 {
_M_ptr = 0x0000000001ad2c10
}
module_sp = std::__shared_ptr<lldb_private::Module, 4>::element_type @ 0x0000000001ad74c0 {
_M_ptr = 0x0000000001ad74c0
}
comp_unit = 0x0000000001b68f30
function = nullptr
block = nullptr
line_entry = {
range = {
m_base_addr = {
m_section_wp = std::__weak_ptr<lldb_private::Section, 4>::element_type @ 0x0000000001acf0d0 {
_M_ptr = 0x0000000001acf0d0
}
m_offset = 1548
}
m_byte_size = 4
}
file = {
m_directory = (m_string = "/tmp/XXXX.stub2762")
m_filename = (m_string = "__lib_XXXXXXXXXXXXXXX_stub_gen.s")
m_is_resolved = false
m_style = posix
}
original_file = {
m_directory = (m_string = "/tmp/XXXX.stub2762")
m_filename = (m_string = "__lib_XXXXXXXXXXXXXXX_stub_gen.s")
m_is_resolved = false
m_style = posix
}
line = 61
column = 0
is_start_of_statement = 1
is_start_of_basic_block = 0
is_prologue_end = 0
is_epilogue_begin = 0
is_terminal_entry = 0
}
symbol = 0x0000000001aff7e8
variable = nullptr
}
jimingham
commented
2 years ago lldb expects that if you are stopped in a frame with debug information we should be able to make a function object, so we don't check that the function is valid. I put up:
https://reviews.llvm.org/D119297
for review, that just checks that we actually have a function before accessing it, and returns an error from "thread until".
Using lldb-13.0.0 on x86_64, debugging a powerpc target via gdb-remote, encountered a crash while running
thread until <addr>.backtrace in the corefile is a little different: