In 88f409194, we changed the way the crashlog scripted process was
launched since the previous approach required to parse the file twice,
by stopping at entry, setting the crashlog object in the middle of the
scripted process launch and resuming it.
Since then, we've introduced SBScriptObject which allows to pass any
arbitrary python object accross the SBAPI boundary to another scripted
affordance.
This patch make sure of that to include the parse crashlog object into
the scripted process launch info dictionary, which eliviates the need to
stop at entry.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch addresses 2 issues:
1. It makes registers available on non-crashed threads all the time
2. It fixes arm64 registers parsing for registers that don't use the `x`
prefix (`fp` -> `x29` / `lr` -> `x30`)
---------
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch makes interactive mode as the default when using the crashlog
command. It replaces the existing `-i|--interactive` flag with a new
`-m|--mode` option, that can either be `interactive` or `batch`.
By default, when the option is not explicitely set by the user, the
interactive mode is selected, however, lldb will fallback to batch mode
if the command interpreter is not interactive or if stdout is not a tty.
This also adds some railguards to prevent users from using interactive
only options with the batch mode and updates the tests accordingly.
rdar://97801509
Differential Revision: https://reviews.llvm.org/D141658
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This fixes a typo when creating a target from the crashlog script and
that we were not able to find a valid architecture from the crash
report.
rdar://137344016
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
This patch makes interactive mode as the default when using the crashlog
command. It replaces the existing `-i|--interactive` flag with a new
`-m|--mode` option, that can either be `interactive` or `batch`.
By default, when the option is not explicitely set by the user, the
interactive mode is selected, however, lldb will fallback to batch mode
if the command interpreter is not interactive or if stdout is not a tty.
This also adds some railguards to prevent users from using interactive
only options with the batch mode and updates the tests accordingly.
rdar://97801509
Differential Revision: https://reviews.llvm.org/D141658
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This PR removes the `target-aarch64` requirement on the crashlog tests
to exercice them on Intel bots and make image loading single-threaded
temporarily while implementing a fix for a deadlock issue when loading
the images in parallel.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch changes the crashlog image loading default behaviour to not
only load images from the crashed thread but also for the application
specific backtrace thread.
This patch also move the Application Specific Backtrace / Last Exception
Backtrace tag from the thread queue field to the thread name.
rdar://128276576
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch adds the `--no-parallel-image-loading` to the crashlog
command. By default, image loading will happen in parallel in the
crashlog script however, sometimes, when running tests or debugging the
crashlog script itself, it's better to load the images sequentially.
As its name suggests, this flag will disable the default image loading
behaviour to load all the images sequencially in the main thread.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
In lldb, users can change the `dsymForUUID` binary using the
`LLDB_APPLE_DSYMFORUUID_EXECUTABLE` environment variable.
This patch changes the crashlog to support the same behaviour as lldb
and uses this environment variable to disable `dsymForUUID` lookups in
crashlog test by having it be empty. Since CI bots shoudn't have access
to images on build records, it doesn't make sense to make use of
`dsymForUUID` in tests.
rdar://128953725
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This should fix the various crashlog test failures on the bots:
```
lldb-shell :: ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test
lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_json.test
lldb-shell :: ScriptInterpreter/Python/Crashlog/interactive_crashlog_legacy.test
lldb-shell :: ScriptInterpreter/Python/Crashlog/last_exception_backtrace_crashlog.test
lldb-shell :: ScriptInterpreter/Python/Crashlog/skipped_status_interactive_crashlog.test
```
When we create a target by using the command option, we don't set it in
the crashlog object which later on cause us to fail loading the images.
rdar://127832961
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch fixes a bug in when resolving and loading modules from the
binary image list.
When loading a module, we would first use the UUID from the binary image
list with `dsymForUUID` to fetch the dSYM bundle from our remote build
records and copy the executable locally.
If we failed to find a matching dSYM bundle for that UUID on the build
record, let's say if that module was built locally, we use Spotlight
(`mdfind`) to find the dSYM bundle once again using the UUID.
Prior to this patch, we would set the image path to be the same as the
symbol file. This resulted in trying to load the dSYM as a module in
lldb, which isn't allowed.
This patch address that by looking for a binary matching the image
identifier, next to the dSYM bundle and try to load that instead.
rdar://127433616
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch rephrases the crashlog `--no-crashed-only` option help
message. This option is mainly used in batch mode to symbolicate and
dump all the threads backtraces, instead of only doing it for the
crashed thread which is the default behavior.
rdar://127391524
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
In `27f27d1`, we changed the image loading logic to conform to the
various options (`-a|--load-all` & `-c|--crashed-only`) and loaded them
concurrently.
However, instead of the subset of images that matched the user option,
the thread pool would always run on all the crashlog images, causing
them to be all loaded in the target everytime.
This matches the `-a|--load-all` option behaviour but depending on the
report, it can cause lldb to load thousands of images, which can take a
very long time if the images are downloaded over the network.
This patch fixes that issue by keeping a list of `images_to_load` based
of
the user-provided option. This list will be used with our executor
thread pool to load the images according to the user selection, and
reinstates
the expected default behaviour, by only loading the crashed thread
images and
skipping all the others.
This patch also unifies the way we load images into a single method
that's shared by both the batch mode & the interactive scripted process.
rdar://123694062
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch should address some register parsing issue in the legacy
report format.
rdar://107210149
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
On macOS, we usually use the DebugSymbols framework to find dSYMs, but
we have a few places (including crashlog.py) that calls out directly to
dsymForUUID. Currently, this invocation is missing two important
options:
* `--ignoreNegativeCache`: Poor network connectivity or lack of VPN can
lead to a negative cache hit. Avoiding those issues is worth the penalty
of skipping these caches.
* `--copyExecutable`: Ensure we copy the executable as it might not be
available at its original location.
rdar://118480731
In 21a597c, we fixed a module loading issue by using the new
`argparse.BooleanOptionalAction`. However, this is only available
starting python 3.9 and causes test failures on bots that don't fulfill
this requirement.
To address that, this patch replaces the use of `BooleanOptionalAction`
by a pair of 2 opposite `store` actions pointing to the same destination
variable.
Differential Revision: https://reviews.llvm.org/D158452
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch fixes TestSaveCrashlog.py failure introduces by eef5eadbe617,
which restricts the number of positional argument for the output file to 1.
I expected to get the output file but `argparse` puts the object in a
list (even by constrained to a singled positional argument).
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
When using the `crashlog` command in batch mode, most users only care
about the crashed thread and end up having to scroll past all the
non-crashed threads, which is not a good user experience.
Now that `-c|--crashed-only` is set by default, we should also apply
that behavior for batch mode: Only the crashed thread and "Application
Specific Backtrace" threads will be shown to the user in batch mode.
The user will still have the ability to show all the threads if they use
`--no-crashed-only` which will parse the symbols from the report, or
with `-a|--load-all-images` which will fetch binaries and debug info
from the build record and symbolicate every thread.
rdar://106329893
Differential Revision: https://reviews.llvm.org/D157852
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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 <ismail@bennani.ma>
Before 27f27d15f, the `crashlog` command would always load images even
if `-a` or `-c` was not set by the user.
Since that change, images are loaded only when one of these 2 flags are
set, otherwise, we fallback to parsing the symbols from the report and
load them into a `SymbolFileJSON`.
Although that makes it way faster than pulling binaries and debug
symbols from build records, that cause a degraded experience since none
of our users are used to set these 2 flags. For instance, that would
symbolicate the backtraces, however the users wouldn't see sources.
To address that change of behavior, this patch changes the default value
for the `-c|--crash-only` flag to `true`. On the other hand, thanks to
the move to `argparse`, we introduced a new `--no-only-crashed` flag
that will let the user force skipping loading any images, relying only
on the `SymbolFileJSON`.
This gives the users a good compromise since they would be able to see
sources for the crashed thread if they're available, otherwise, they'll
only get a symbolicated backtrace.
Differential Revision: https://reviews.llvm.org/D157850
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch replace the deprecated `optparse` module used for the
`crashlog`& `save_crashlog` commands with the new `argparse` from the
python standard library. This provides many benefits such as showing the
default values for each option in the help description, but also greatly
improve the handling of position arguments.
Differential Revision: https://reviews.llvm.org/D157849
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Prior to this patch, when a user loaded multiple crash report in lldb,
they could get in a situation where all the targets would keep the same
architecture and executable path as the first one that we've created.
The reason behind this was that even if we created a new CrashLog
object, which is derived from a Symbolicator class that has a newly
constructoted image list as a default argument, because that default
argument is only created once when the function is defined, every CrashLog
object would share the same list.
That will cause use to append newly parsed images to the same
Symbolicator image list accross multiple CrashLog objects.
To address this, this patch changes the default argument value for the
image parameter to `None` and only initialize it as an empty list when
no argument was passed.
This also removes the image list stored in each CrashLog parsers since
they shouldn't have any state and should be re-usable. So now, the only
source of truth is stored in the CrashLog object.
rdar://84984949
Differential Revision: https://reviews.llvm.org/D157044
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch changes the parsing logic for the legacy crash report format
to avoid interrupting the parsing if there are new lines in the middle
of a section.
To do, the parser starts to skip all consecutive empty lines. If the
number of lines skipped is greater than 1, the parser considers that it
reached a new setion of the report and should reset the parsing mode to
back to normal.
Otherwise, it tries to parse the next line in the current parsing mode.
If it succeeds, the parser will also skip that line since it has already
been parsed and continue the parsing.
rdar://107022595
Differential Revision: https://reviews.llvm.org/D157043
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch changes the way we dump the registers from the legacy
crashlog command to make sure that the ordering matches the one from lldb.
rdar://109172073
Differential Revision: https://reviews.llvm.org/D156919
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
It can be tricky to troubleshoot why the crashlog script can't show
inline sources. The two most common causes are that we couldn't find the
dSYM or, if we find the dSYM, that the path remapping included in the
dSYMForUUID output isn't accessible. The former is already easy to
diagnose, but the latter is harder because you'd have to manually invoke
dsymForUUID on the UUID and check the remapped path. This patch
automates that process and prints a warning if the remapped path doesn't
exist or is not accessible.
Differential revision: https://reviews.llvm.org/D152886
Run crashlog inside lldb when invoked in interactive mode from the
command line. Currently, when passing -i to crashlog from the command
line, we symbolicate in LLDB and immediately exit right after. This
pretty much defeats the purpose of interactive mode. That said, we
wouldn't want to re-implement the driver from the crashlog script.
Re-invoking the crashlog command from inside LLDB solves the issue.
rdar://97801509
Differential revision: https://reviews.llvm.org/D152319
This fixes a regression introduced by 27f27d15f6c9 that results in a
NameError: (name 'self' is not defined) when using crashlog with the -c
option.
rdar://110007391
This patch should fix a crash in the opening a crash report that was
passed with a relative path.
This patch expands the crash report path before parsing it and raises a
`FileNotFoundError` exception if the file doesn't exist.
Differential Revision: https://reviews.llvm.org/D152012
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch should allow the user to set specific auto-completion type
for their custom commands.
To do so, we had to hoist the `CompletionType` enum so the user can
access it and add a new completion type flag to the CommandScriptAdd
Command Object.
So now, the user can specify which completion type will be used with
their custom command, when they register it.
This also makes the `crashlog` custom commands use disk-file completion
type, to browse through the user file system and load the report.
Differential Revision: https://reviews.llvm.org/D152011
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch changes the way we load a crash report into a scripted
process by creating a empty target.
To do so, it parses the architecture information from the report (for
both the legacy and json format) and uses that to create a target that
doesn't have any executable, like what we do when attaching to a process.
For the legacy format, we mostly rely on the `Code Type` line, since the
architure is an optional field on the `Binary Images` sections.
However for the json format, we first try to get the architecture while
parsing the image dictionary if we couldn't find it, we try to infer it
using the "flavor" key when parsing the frame's registers.
If the architecture is still not set after parsing the report, we raise
an exception.
rdar://107850263
Differential Revision: https://reviews.llvm.org/D151849
Differential
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch should address the crashes when parsing a the crash report
frame dictionary.
If the crash report is not symbolicated, the `symbolLocation` key will
be missing. In that case, we should just use the `imageOffset`.
rdar://109836386
Differential Revision: https://reviews.llvm.org/D151844
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
Following abba5de72466, some tests started failing on green-dragon:
https://green.lab.llvm.org/green/job/lldb-cmake/55460/console
Looking at the backtrace, there seems to be a racing issue when deleting
the temporary directory containing all the JSON object files:
```
Traceback (most recent call last):
File "/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/python3.10/site-packages/lldb/macosx/crashlog.py", line 1115, in __call__
SymbolicateCrashLogs(debugger, shlex.split(command), result)
File "/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/python3.10/site-packages/lldb/macosx/crashlog.py", line 1457, in SymbolicateCrashLogs
SymbolicateCrashLog(crash_log, options)
File "/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/python3.10/site-packages/lldb/macosx/crashlog.py", line 1158, in SymbolicateCrashLog
with tempfile.TemporaryDirectory() as obj_dir:
File "/usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10/tempfile.py", line 869, in __exit__
self.cleanup()
File "/usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10/tempfile.py", line 873, in cleanup
self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
File "/usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10/tempfile.py", line 855, in _rmtree
_shutil.rmtree(name, onerror=onerror)
File "/usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10/shutil.py", line 731, in rmtree
onerror(os.rmdir, path, sys.exc_info())
File "/usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10/shutil.py", line 729, in rmtree
os.rmdir(path)
OSError: [Errno 66] Directory not empty: '/var/folders/09/r4vw4v8n5kb67jl66zvlbljw0000gn/T/tmp6qfifxk7'
```
This patch should fix that issue since it won't delete the object file
directory until we're sure that the modules adding tasks completed.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch changes the way we generate the ObjectFileJSON files
containing the inlined symbols from the crash report to remove the
tempfile prefix from the object file name.
To do so, instead of creating a new tempfile for each module, we create a
temporary directory that contains each module object file with the same
name as the module.
This makes the backtraces only contain the module name without the
temfile prefix which makes it look like a regular stackframe.
Differential Revision: https://reviews.llvm.org/D151045
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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>
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
Now that we can pass Python objects to the scripted process instance, we
don't need to parse the crashlog twice anymore.
Differential revision: https://reviews.llvm.org/D148063
When using interactive crashlog from an IDE, it can happen that the user
already have the `command script import lldb.macosx.crashlog` command on
their `lldbinit` file.
That leads to showing some message:
```
error: cannot add command: user command exists and force replace not set
error: cannot add command: user command exists and force replace not set
```
This leads to confusion because the crashlog symbolication continues and
succeeds even after these errors.
To address that, the crashlog commands get overridden everytime the
script get re-imported.
rdar://103403943
Differential Revision: https://reviews.llvm.org/D140113
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch should fix an undefined behaviour that's happening when
parsing a crash report from an IDE. In the previous implementation, the
CrashLogParser base class would use the `__new__` static class method to
create the right parser instance depending on the crash report type.
For some reasons, the derived parser initializer wouldn't be called when
running the command from an IDE, so this patch refactors the
CrashLogParser code to replace the use of the `__new__` method with a
factory `create` static method.
rdar://100527640
Differential Revision: https://reviews.llvm.org/D139951
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch replaces the backing file path key to "file_path" to keep it
consistent.
rdar://101652618
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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 <medismail.bennani@gmail.com>
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 <medismail.bennani@gmail.com>
This patch updates the image_regex_uuid matcher to match null-UUID
images in the plain text crashlog parser.
It updates the regex to match one or more '?' characters or the image
full path.
rdar://100904019
Differential Revision: https://reviews.llvm.org/D135482
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
