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>
I know it was my idea to have this on the SBTarget class, but I think we should move this once more :/. I mean, this is definitely better than the SBPlatform class (which is what I was really trying to say before), but I think SBProcess would be even better here. The SBTarget methods are things that (more or less) make sense even when you don't have an actual process around. However, "crash info" (I think) only makes sense once you have an actual process, and so it would make sense to have it somewhere near SBProcess::GetState/GetDescription. It would also be more symmetric with the CLI interface for this, which lives under the "process" command tree.
The internal interfaces might also be better off passing a Process object (instead of Target) around, but that is not as important..
Sorry. :(