Allow user reported exceptions to not suspend all threads

[snmaynard]

Suspending all threads for user reported exceptions in games can cause a noticeable lag while the report is being generated so I've added a flag to control that functionality.

[kstenerud]

Hmm this could get a little dangerous. Trying to walk the stack trace of a running thread is just asking for trouble. Also, it would no longer be a snapshot of exactly where each thread was in relation to each other at the time of the crash.

If it's just the user portion that's causing problems, maybe we can only suspend the threads while they are being traced and then turn them back on afterwards?

[snmaynard]

I toyed with that but its a little tricky to allow the other sentries to still lock all the threads (which presumably they need to do in the event of a terminal crash?)

Its easy to do if all sentries can rely on the threadwalker to lock the threads, but im not sure that's appropriate? I could possibly check to see if the threads are already locked further down and lock them if the usersentry has left the threads running?

If you let me know what approach is best I can throw the code together.

[kstenerud]

They only need to lock down the threads to ensure that the threads are all in the exact state they were in at the time of the crash. Technically, the threads only need to remain locked while the stack trace is generated. Once that's been saved, they can be restarted again.

Probably the best way to tackle this would be to allow the sentries to lock the threads, as they do now. Then, in KSCrashReport.c, move the writeAllThreads and writeMemoryInfo stuff up so that it gets written earlier, then unlock the threads and continue with the rest of the report, since the rest of the stuff is not temporal.

So then the order would be: lock threads (in the sentry), in kscrashreport_writeStandardReport call writeReportInfo, writeAllThreads, writeError, writeMemoryInfo, writeAppStats, unlock threads, write the rest of the report components

[kstenerud]

Gimme a few days to finish another feature I'm working on. This sort of change requires a level of thread safety that's not in the lower core yet.

[kstenerud]

Basically a lot of things need to be changed from global allocation to stack allocation (or even heap, where possible).

[rapinto]

Hi, same issue for me. I have several custom errors (maybe 20 errors) fired in a short period time, and suspending all threads is visually noticable.
If I comment the : kscrashsentry_suspendThreadsand kscrashsentry_resumeThreads it removes the lag.

Any advices? Is it worth to wait for you to take a look at this?

[kstenerud]

I'm working on thread safety as we speak :)

[croustibapt]

Really good news! Many thanks man!