我在大型代码库中遇到了这段代码
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);
}
我的问题是:为什么使用线程?如果ThreadFunc
中的代码直接在Manager::Crash
中完成,那么它会更多或更少线程安全吗?如果我删除了崩溃,我不愿意做出更改。
答案 0 :(得分:5)
他不想处理发生的异常。收到Manager::Crash
的原始主题仍在继续。 AV异常不一定终止该过程。虽然在这种情况下,事件不是由__try/__except
块处理的(注意,是SEH try block,而不是C ++),然后未处理的second chance异常将终止流程。但也许他想强制Dr. Watson / WER跳入,或post-mortem debugger启动,或者进入当前的调试器。谁知道......
其实,噢!如果主线程确实安装了 SEH处理程序,它将不会使进程崩溃。 QED。
答案 1 :(得分:1)
你需要先询问程序员编写的内容,但可能在这样的线程中崩溃的理由是绕过一个异常处理程序,用于捕获主线程中的段错误。这可能是打破源控制的延时视图并通过电子邮件发送给犯罪者的好时机。
顺便说一句,这也是一种不必要的笨拙方式来引发CPU异常。您可以使用例如 __debugbreak()或内联汇编int 3
直接触发崩溃或断点。这将导致程序立即进入调试器,默认情况下,如果没有连接调试器,大多数MSVC程序将转储核心。
答案 2 :(得分:0)
除非你在我们没有看到的主题之后有更多的工作要做,否则我没有看到这个原因在一个单独的线程中。我猜主线程由于某种原因捕获它。当它发生时我宁愿抓住它,然后亲自将它渗透到顶层。
为什么要崩溃服务器?听起来像是一个糟糕的设计选择。