I am a bot that can symbolize Flutter Engine crashes. If you have any bug reports or questions contact @mraleph
I can automatically detect the following crashes:
- Android crashes marked with
*** *** *** ... *** *** ***line.
- iOS crashes starting with
Incident Identifier: ...line.
For symbolization I would need to know engine commit hash and build mode. I
support extracting engine version from
flutter doctor output (with or
-v) and I can sometimes guess build mode (e.g. by using
included into stack traces on Android).
However often reports don't include all required information or don't use native format so you would need to provide me with additional hints, see Commands below.
When you mention me in the comment you can include a number of symbolization overrides which would fill in the gaps in information for me.
@flutter-symbolizer-bot [engine#<sha>|flutter#v<commit>] [profile|release|debug] [x86|arm|arm64|x64]
@flutter-symbolizer-bot MUST be the very first thing
in your comment.
engine#<sha>allows to specify which engine commit I should use;
flutter#v<commit>allows to specify which Flutter Framework commit I should use (this is just another way of specifiying engine commit). Note
flutter#v- this prevents linkifying which would otherwise confuse the bot;
profile|release|debugtells me which build mode I should use (iOS builds only have
releasesymbols available though);
x86|arm|arm64|x64tells me which architecture I should use.
You can point me to a specific comment by including the link to it:
link, which looks like
https://github.com/flutter/flutter/issues/ISSUE#issue(comment)?-ID, asks me to look for crashes in the specific comment;
thisasks me to symbolize content of the comment which contains the command.
If your backtrace comes from Crashlytics with lines that look like this:
4 Flutter 0x106013134 (Missing)
You would need to tell me
@flutter-symbolizer-bot force ios [arm64|arm] [engine#<sha>|flutter#v<commit>] link|this:
force iostells me to ignore native crash markers and simply look for lines that match
[arm64|arm]gives me information about architecture, which is otherwise missing from the report;
engine#sha|flutter#v<commit>gives me engine version (note
flutter#v- this prevents linkifying which would otherwise confuse the bot);
link|thisspecifies which comment to symbolize. Note
⚠️: because this is a departure from native crash report formats you must tell me which comment to symbolize manually
If your backtrace has lines that look like this:
0x0000000105340708(Flutter + 0x002b4708)
You would need to tell me
@flutter-symbolizer-bot internal [arm64|arm] [engine#<sha>|flutter#<commit>] link|this:
internaltells me to ignore native crash markers and look for lines that match internal backtrace format.
Note about Relative PCs
To symbolize stack trace correctly I need to know PC relative to binary image load base. Native crash formats usually include this information:
- On Android
pccolumn actually contains relative PCs rather then absolute. Though Android versions prior to Android 11 have issues with their unwinder which makes these relative PCs skewed in different ways (see this bug for more information). I try my best to correct for these known issues;
- On iOS I am looking for lines like this
Flutter + <rel-pc>which gives me necessary information.
Some crash formats (Crashlytics) do not contain neither load base nor relative PCs. In this case I try to determine load base heuristically based on the set of return addresses available in the backtrace: I look through Flutter Engine binary for all call sites and then iterate through potential load bases to see if one of them makes all of PCs present in the backtrace fall onto callsites. The pattern of call sites in the binary is often unique enough for me to be able to determine a single possible load base based on 3-4 unique return addresses.