Currently, in macOS, when a process crashes, lldb halts inside the
implementation disassembly without yielding any useful information.
The only way to get more information is to detach from the process, then wait
for ReportCrash to generate a report, find the report, then see what error
message was included in it. Instead of waiting for this to happen, lldb could
locate the error_string and make it available to the user.
This patch addresses this issue by enabling the user to fetch extended
crash information for crashed processes using process status --verbose.
Depending on the platform, this will try to gather different crash information
into an structured data dictionnary. This dictionnary is generic and extensible,
as it contains an array for each different type of crash information.
On Darwin Platforms, lldb will iterate over each of the target's images,
extract their __crash_info section and generated a StructuredData::Array
containing, in each entry, the module spec, its UUID, the crash messages
and the abort cause. The array will be inserted into the platform's
m_extended_crash_info dictionnary and FetchExtendedCrashInformation will
return its JSON representation like this:
{ "crash-info annotations": [ { "abort-cause": 0, "image": "/usr/lib/system/libsystem_malloc.dylib", "message": "main(76483,0x1000cedc0) malloc: *** error for object 0x1003040a0: pointer being freed was not allocated", "message2": "", "uuid": "5747D0C9-900D-3306-8D70-1E2EA4B7E821" }, ... ], ... }
This crash information can also be fetched using the SB API or lldb-rpc protocol
using SBTarget::GetExtendedCrashInformation().
rdar://37736535
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
If we keep the this way, then the user will have to remember to get the correct platform in order to ask it for the crash info. That's not the end of the world, but it might be better if this was a method on the SBTarget class, which would automatically consult the target's current platform.