Are there advantages to a crashing on a secondary thread versus the main one?

Question

I came across this code in a large codebase

DWORD WINAPI ThreadFunc (LPVOID lpParam)
{ 
    int *x = 0;
    *x = 1234; // Access violation

    return 0; 
}

void Manager::Crash ()
{
    Log("Received a remote command to crash Server.");

    DWORD dwThreadId, dwThrdParam = 1; 
    HANDLE hThread = ::CreateThread(NULL, 0, ThreadFunc, &dwThrdParam, 0, &dwThreadId);
} 

My question is: Why is it using a thread? Would it be more or less threadsafe if the code in ThreadFunc was done directly in Manager::Crash? I am reluctant to make changes in case I remove the crash.

Answer 1

He doesn't want to handle the exception that occurs. The original thread that received the Manager::Crash continues. An AV exception does not necessarily terminate the process. Although in this case the fact that is not handled by a __try/__except block (note, is a SEH try block, not the C++ one) then the unhandled second chance exception will terminate the process. But perhaps he want to force Dr. Watson/WER to jump in, or the post-mortem debugger to launch, or to break into current debugger. Who knows...

Actually, d'oh! IF the main thread does have a SEH handler installed, it will not crash the process. QED.

Answer 2

I don't see a reason for this to be in a separate thread unless you have more work to do after the thread that we are not seeing. I'm guessing that the main thread catches it for some reason. I'd rather catch it when it happens then have it percolate to the top personally.

Why crash the server? Sounds like a poor design choice to me.

Answer 3

You'd need to ask whichever programmer wrote it in the first place, but probably the rationale behind crashing in a thread like that was to get around an exception handler designed to catch segfaults in the main thread. This might be a good time to break out your source control's time-lapse view and email the perpetrator.

That's also an unnecessarily clumsy way to induce a CPU exception, by the way. You can trigger a crash or breakpoint directly by using eg __debugbreak() or an inline assembly int 3. That will cause the program to break into the debugger immediately, which by default in most MSVC programs will dump core if no debugger is attached.