暴雪团队使用VS进行Linux平台崩溃分析蝎子简介说说我们的调试工作流程总结最后( 二 ) ：暴雪团队使用VS进行Linux平台

然后，我们切换到VisualStudio ，真正有意思的地方开始了。我们加载解决方案以构建Windows版本的服务器。然后，我们在“调试”->“其他调试目标”->“仅使用本机调试Linux核心转储”下打开新的调试对话框。我们启用“在WSL上调试”复选框，并填写转储文件和服务器二进制文件的(特定于WSL！)路径。之后，我们点击“调试” ，就可以开始愉快的调试了！

文章图片
VisualStudio在后台调用WSL中的GDB 。在进行一些磁盘活动之后， VS会弹出一个崩溃的调用堆栈，指令指针位于相关代码行上。这是一个勇敢的新世界！
因此，接下来是识别崩溃的任务。我们有一个崩溃处理程序来拦截崩溃以执行一些记录工作，因此实际崩溃将落在单线程服务器中的调用堆栈中。但是，我们的某些服务器是多线程的，崩溃可能是由这些线程中的任何一个引起的。我们的崩溃处理程序会记录崩溃文件和行的来源，因此检查这些变量可为我们提供第一个线索；我们将查找执行该代码的调用堆栈。
在几周前的过去，我们将使用GDB获取所有线程的回溯并仔细阅读结果列表，以查看哪个线程具有最有可能崩溃的调用堆栈。例如，如果一个线程仅在休眠，则很可能不是崩溃的线程。我们将寻找一个栈，该栈的内容要多于几个带有“睡眠”的帧，然后检查代码以查看问题是否明显，或者进入GDB本身以检查进程状态。
但是， VisualStudio为我们提供了强大得多的选项。对于多线程内核，可以在调试会话中打开“线程”窗口，并在每个线程中四处查看以查看堆栈的外观。这与gdb方法非常相似，如果有50个线程，可能会非常乏味。幸运的是，有一个功能可以使此操作变得容易得多：并行堆栈。
我承认，直到ErikaSweet和她的团队告诉我们，我们大多数人都不了解ParallelStacks 。调用Debug->Windows->ParallelStacks（仅在调试会话期间可用）会打开一个新窗口，其中显示了进程中每个线程的调用堆栈。这是整个进程空间的一个迷人视图。你可以双击任何线程中的任何堆栈框架， VisualStudio会在源和调用堆栈窗口中都跳转到该框架。对于我们来说，这是一个非常节省的时间。
一旦我们可以看到崩溃附近的代码，就可以使用鼠标悬停， QuickWatch或VisualStudio中的其他任何工具检查变量。的确，在发布版本中，许多变量已被优化，但同时许多变量还没有被优化！与使用GDB相比，使用VisualStudio界面可以更快地解决问题。

文章图片
总结我们的开发团队对于从VisualStudio的生产环境中调试Linux内核的能力感到非常兴奋！对于我们来说，这是一个改变游戏规则的方法，因为它使更多开发人员可以“狂野地”主动诊断问题，并且它使我们所有人都可以使用功能强大的VisualStudio调试工具集。初始设置完成后，只需一分钟左右的时间即可在VisualStudio中进行调试。此功能将使我们的代码中发现问题的速度更快，更有效！感谢Erika和她的团队在此方面与我们合作！
最后MicrosoftVisualC++团队的博客是我非常喜欢的博客之一，里面有很多关于VisualC++的知识和最新开发进展。大浪淘沙，如果你对VisualC++这门古老的技术还是那么感兴趣，则可以经常去他们那(或者我这)逛逛。
本文来自：《BlizzardDiabloIVdebugsLinuxcoredumpsfromVisualStudio》

文章图片