7bdeef54a2
Team: - Adjust report generation event to include a final status code for listeners. CliContext,TeamWindow,ReportUserinterface: - Use aforementioned status code to indicate whether report generation succeeded or failed. DebugReportGenerator: - Notify listeners if report generation fails. This may have previously been responsible for some bug reports where it was indicated that the debugger hung without exiting after being asked to save a report from a crashed app. - When dumping disassembly, retrieve it directly if necessary rather than requesting it via the user interface listener. This also fixes the quirk that requesting to save a crash report while looking at the source code of a function would trigger switching it to disassembly visually. - When walking the list of threads to dump, acquire references to all of them before starting. Otherwise, it was potentially possible for a running but not crashed thread to exit while we were generating the report, leaving us with a pointer to a deleted thread. This was most likely the cause of one of the crashes reported in #13082. - When receiving the notification that source code state has changed, clear the waiting function. Otherwise, it was potentially possible for us to get other state change notifications, leading to the data semaphore being released too often. This would then cause later potential waits such as the stack frame memory dump to not actually wait when they should, potentially leading them to dereference objects that weren't yet ready. This fixes another of the crashes in #13802. |
||
---|---|---|
.. | ||
build | ||
clang | ||
compatibility | ||
config | ||
cpp | ||
glibc | ||
libs | ||
os | ||
posix | ||
private | ||
tools |