summaryrefslogtreecommitdiff
path: root/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/interactive_crashlog
AgeCommit message (Collapse)Author
2023-08-18[lldb/crashlog] Add test for 8f75c4d01eff3c65d7ae40bfd05582de7dffa590 (NFC)Med Ismail Bennani
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-06-01[lldb/crashlog] Add test for non-symbolicated report crashMed Ismail Bennani
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-05-19[lldb/crashlog] Load inlined symbol into interactive crashlogMed Ismail Bennani
Sometimes, crash reports come with inlined symbols. These provide the exact stacktrace from the user binary. However, when investigating a crash, it's very likely that the images related to the crashed thread are not available on the debugging user system or that the versions don't match. This causes interactive crashlog to show a degraded backtrace in lldb. This patch aims to address that issue, by parsing the inlined symbols from the crash report and load them into lldb's target. This patch is a follow-up to 27f27d1, focusing on inlined symbols loading from legacy (non-json) crash reports. To do so, it updates the stack frame regular expression to make the capture groups more granular, to be able to extract the symbol name, the offset and the source location if available, while making it more maintainable. So now, when parsing the crash report, we build a data structure containing all the symbol information for each stackframe. Then, after launching the scripted process for interactive mode, we write a JSON symbol file for each module, only containing the symbols that it contains. Finally, we load the json symbol file into lldb, before showing the user the process status and backtrace. rdar://97345586 Differential Revision: https://reviews.llvm.org/D146765 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-04-13[lldb] Use ObjectFileJSON to create modules for interactive crashlogsJonas Devlieghere
Create an artificial module using a JSON object file when we can't locate the module and dSYM through dsymForUUID (or however locate_module_and_debug_symbols is implemented). By parsing the symbols from the crashlog and making them part of the JSON object file, LLDB can symbolicate frames it otherwise wouldn't be able to, as there is no module for it. For non-interactive crashlogs, that never was a problem because we could simply show the "pre-symbolicated" frame from the input. For interactive crashlogs, we need a way to pass the symbol information to LLDB so that it can symbolicate the frames, which is what motivated the JSON object file format. Differential revision: https://reviews.llvm.org/D148172
2022-08-09[lldb/crashlog] Skip null image dsym fetching on interactive modeMed Ismail Bennani
Sometimes, it can happen that a crash report has null images in its list of used binaries. This manifests like such: ``` 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ??? ``` When fetching debug symbols to symbolicate the crashlog stackframe, having null images causes `dsymForUUID` to hang for few seconds. This patch addresses that by skipping null images from being load by the scripted process. rdar://97419487 Differential Revision: https://reviews.llvm.org/D131038 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-08-09[lldb/crashlog] Fix interactive crashlog testMed Ismail Bennani
This patch should fix the interactive crashlog test by checking in the binary as a yaml to regeneate the binary with the addresses and offsets when running the test. rdar://93655633 Differential Revision: https://reviews.llvm.org/D129603 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>