- The function reporting the crash on the pipe doesn't need to suspend all the threads. The original purpose for suspending the threads was likely to preserve the state of the process as best as possible, but that is not required and prone to deadlocks.
Not suspending all the threads may would fix the hyphotetical case where CRC main thread is waiting for a prior ensure call stack to get resolved - I observed degenerated cases on my machine where this could take more than 15 minutes - preventing it to respond promptly to an incoming crash from the Editor. The flow was as following:
- Editor fires an ensure, suspends all the thread, pipe a message to CRC to process the ensure.
- CRC collects the ensure artefacts quickly, replies to the Editor, the Editor resumes, then CRC starts to resolve the call stack (blocking the main thread) from the minidump - degenerated cases can take several minutes.
- Editor gets CRC messages and resumes its threads.
- Editor fires a crash, suspends all the threads, pipes a message to CRC to process the crash.
- CRC main thread is busy, waiting for the previous ensure call stack to be resolved... and doesn't respond promptly to the crash message.
- Editor threads behing suspended, the code responsible to timeout if CRC takes too long never executes and Editor stalls until CRC dies or responds -> The user likely kills the Editor (and possibly CRC).
As a side effect from this change, if CRC doesn't respond promptly to a crash, the thread calling ReportCrash( )/ReportGPUCrash( ) will timeout and likely terminate the Editor before CRC could collect the crash artifacts or walk the thread to collect the call stacks.
- Added a hint to the diagnostic logs reported with the Editor 'SummaryEvent' analytic event to indicate if the crash report was produced after the Editor died, so that the portable call stack wasn't captured.
- Added a message displayed to the user by CRC saying that the the system failed to capture the callstack.
#jira UE-108701 - Editor deadlocks when reporting an ensure, a stall or a crash.
#rb Johan.Berg
[CL 15452515 by Patrick Laflamme in ue5-main branch]
- Changed the execution flow to ensure the callstack was displayed while the windows was still on screen (it was updated just after the window was closed).
#rb Johan.Berg
#ROBOMERGE-SOURCE: CL 11565572 in //UE4/Release-4.25/... via CL 11565573
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v654-11333218)
[CL 11581626 by patrick laflamme in Main branch]
- Prevented CrashReportClient::FinalizeDiagnoseReportWorker() function to called after the CrashReportClient instance was deleted.
Details:
The FDiagnoseReportWorker asynchronous task created an extra asynchronous tasks (calling back CrashReportClient instance) that could fire after the targetted CrashReportClient instance was deleted. The solutions moves the logic to 'finilize' the report in the tick function that is expected to run in the game thread and make 'Close Without Sending' flows like 'Send and Close'/'Send and Restart' but without sending anything.
#rb Francis.Hurteau
#lockdown cristina.riveron
#ROBOMERGE-SOURCE: CL 11462889 in //UE4/Release-4.24/...
#ROBOMERGE-BOT: RELEASE (Release-4.24 -> Main) (v654-11333218)
[CL 11462901 by patrick laflamme in Main branch]
Get GIsRequestingExit now by IsEngineRequestingExit()
Set GIsRequestingExit now by RequestEngineExit(const TCHAR* Reason) or RequestEngineExit(const FString& Reason)
NOTE If Reason is 4 or less chars it will generate an ensure to force a reason to exit
The reason behind this change is right now setting GIsRequestingExit to true can cause many things to break mainly early on and with out any sort of log warning we have entered this state. We should wrap this behind a function to allow for proper handling
#rb Chris.Babcock, Michael.Trepka, Michael.Noland
#jira UE-79933
[FYI] Michael.Noland
#ROBOMERGE-SOURCE: CL 8649683 via CL 8653683
#ROBOMERGE-BOT: (v417-8656536)
[CL 8658680 by brandon schaefer in Main branch]
Remove old CrashReportHelper
Move files dealing with crash upload and reporting to Runtime/CrashReportCore from CrashReportClient
Addition of CrashReporter Plugin in Fortnite for use with IOS
#rb brandon.schaefer, chris.bunner
#ROBOMERGE-OWNER: peter.sauerbrei
#ROBOMERGE-AUTHOR: peter.sauerbrei
#ROBOMERGE-SOURCE: CL 5814730 via CL 5814731 via CL 5814748 via CL 5817030
[CL 5817031 by peter sauerbrei in Main branch]