llvm-project.git/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs, branch main

[lldb] Add support for x86_64h to scripted process (#145099)

2025-06-20T20:28:21+00:00

This patch adds support to the haswell sub-architecture (x86_64h) to
scripted processes.

rdar://147208252

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Fix breaking changes in textual report format (#83861)

2024-03-04T23:44:44+00:00

This patch should address some register parsing issue in the legacy
report format.

rdar://107210149

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Add support for Last Exception Backtrace

2023-08-18T19:50:39+00:00

This patch adds support to the "Last Exception Backtrace" to the
`crashlog` command.

This metadata is homologous to the "Application Specific Backtrace",
however the format is closer to a regular stack frame.

Since the thread that "contains" the "Last Exception Backtrace" doesn't
really exist, this information is displayed when requesting an extended
backtrace of the crashed thread, similarly to the "Application Specific
Backtrace".

To achieve that, this patch includes some refactors and fixes to the
existing "Application Specific Backtrace" handling.

rdar://113046509

Differential Revision: https://reviews.llvm.org/D157851

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Add test for 8f75c4d01eff3c65d7ae40bfd05582de7dffa590 (NFC)

2023-08-18T19:50:39+00:00

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Add test for non-symbolicated report crash

2023-06-02T00:50:55+00:00

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Load inlined symbol into interactive crashlog

2023-05-20T03:08:18+00:00

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

[lldb] Use ObjectFileJSON to create modules for interactive crashlogs

2023-04-13T23:56:29+00:00

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

[lldb/test] Fix app_specific_backtrace_crashlog.test (NFC)

2022-11-15T22:25:52+00:00

This patch changes app_specific_backtrace_crashlog.test's crashlog file
extension from `ips` to `txt. This should prevent the test from opening
Console.app when being run.

This should also fix a test failure caused by missing symbols.

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Fix frame parser regex for when there is no source info

2022-11-05T05:05:58+00:00

It can happen that the originator of a crash report doesn't have access
to certain images. When that's the case, ReportCrash won't show the
source info in the crash report stack frames, but only the stack address
and image name.

This patch fixes a bug in the crashlog stackframe parser regular
expression to optionally match the source info group.

rdar://101934135

Differential Revision: https://reviews.llvm.org/D137466

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Add support for Application Specific Backtraces & Information

2022-11-03T21:44:53+00:00

For an exception crashlog, the thread backtraces aren't usually very helpful
and instead, developpers look at the "Application Specific Backtrace" that
was generated by `objc_exception_throw`.

LLDB could already parse and symbolicate these Application Specific Backtraces
for regular textual-based crashlog, so this patch adds support to parse them
in JSON crashlogs, and materialize them a HistoryThread extending the
crashed ScriptedThread.

This patch also includes the Application Specific Information messages
as part of the process extended crash information log. To do so, the
ScriptedProcess Python interface has a new GetMetadata method that
returns an arbitrary dictionary with data related to the process.

rdar://93207586

Differential Revision: https://reviews.llvm.org/D126260

Signed-off-by: Med Ismail Bennani