与辅助线程相比，在辅助线程上崩溃是否有优势？

我碰到这个代码在一个大的代码库与辅助线程相比，在辅助线程上崩溃是否有优势？

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中完成的，它会或多或少地是线程安全的吗？如果我删除崩溃，我不愿意进行更改。

来源

2010-08-19 Ariel Bold

你从哪里得到这段代码？ – Maz 2010-08-19 23:39:51

有趣的思想实验，但这不是一个伟大的标题。如何“在辅助线程与主要线程之间崩溃是否有优势？” – 2010-08-19 23:42:03

@quixoto：好标题，固定。 @Maz：为什么？ – 2010-08-19 23:43:59

他不想来处理出现的异常。接收到Manager::Crash的原始线程继续。 AV例外不一定终止该过程。虽然在这种情况下，不是由一个__try/__except块处理的事实（注意，是SEH try block，而不是C++一个），则未处理的second chance例外将终止进程。但是也许他想强制Dr. Watson/WER跳进去，或者打开post-mortem debugger，或者打开当前的调试器。谁知道......

事实上，科特迪瓦哦！如果主线程的确有安装了SEH处理程序的，它不会使程序崩溃。 QED。

来源

2010-08-19 23:44:08

我会说，“他不希望任何引发的异常处理。原始线程可能有一个SEH块，并会抓住它。” – GManNickG 2010-08-19 23:45:07

@GMan：Yeap，我很肯定就是这样，避免在主线程中安装任何SEH。在我编辑了我的'D'时刻之后，立刻看到你的评论:) – 2010-08-19 23:50:35

这完全是值得在代码中留言的东西。 – jamesdlin 2010-08-20 00:06:39

我没有看到这是一个单独的线程，除非你有更多的工作，我们没有看到线程后做的一个原因。我猜测主线程出于某种原因捕获它。当它发生时，我宁愿捕捉它，然后让它亲自渗透到顶端。

为什么崩溃服务器？听起来像是一个糟糕的设计选择给我。

来源

2010-08-19 23:45:40

如果您需要测试您的验尸翻车机和错误报告基础设施，那么该如何解决？按需要崩溃进程的方式确实非常方便。 – 2010-08-19 23:47:49

@Remus：这就是为什么有单元测试 – 2010-08-19 23:52:32

@ 0A0D：似乎这可能是一些单元测试基础设施的一部分。 :) – 2010-08-19 23:57:02

你需要问任何一个程序员写在第一位，但很可能在背后这样一个线程崩溃理由是绕过旨在捕获段错误在主线程中的异常处理程序。这可能是打破源代码控制的延时视图并通过电子邮件发送攻击者的好时机。

这也是诱导CPU例外，顺便不必要的笨拙方式。您可以使用直接触发崩溃或断点，例如__debugbreak()或内联程序集int 3。这会导致程序立即中断调试器，如果没有附加调试器，默认情况下，大多数MSVC程序会默认转储内核。

来源

2010-08-19 23:47:40 Crashworks

+1注意，如果你想确保发生这种情况，这是一种相当合理的方式来诱发崩溃。 – 2010-08-19 23:58:26

与辅助线程相比，在辅助线程上崩溃是否有优势？

回答

相关问题