我正在UNIX上使用C / C ++并经常看到核心文件。很多时候核心文件很难调试，以找出核心的实际原因或分段错误。能否请您建议一个高效的调试器？
答案 0 :(得分：11)
对于细分错误，内存泄漏，未初始化的数据等，通过 valgrind 运行程序总是一个好主意。如果您对内存泄漏特别感兴趣，选项“--leak-check = full”会得到回报。
是的，学习gdb。这需要一点时间，但值得。
答案 1 :(得分：9)
我认为大多数* nix支持-g的大多数C编译器都在目标文件中包含调试符号，所以如果你这样做：
cc -g -c file1.c
cc -g -c file2.c
cc -g file1.o file2.o -o program
./program
然后当你运行程序时如果它崩溃了它应该产生一个更容易调试的核心文件。前两行只是编译源文件（生成.o文件），第三行告诉编译器调用链接器将源文件链接到可执行文件（如果链接器执行，那么传递-g可能实际上没有做任何事情不必做任何特殊的事情来生成带有调试符号的可执行文件，但它不应该伤害任何东西），最后一行运行程序。您应该确保在尝试调试时不要告诉编译器进行优化（除非您发现它没有错误，除非启用优化），因为优化通常会使更难以遵循。
由于我不知道您所使用的平台或可用的工具（或者甚至是您正在使用的C编译器），因此很难提供更具体的建议。您应该阅读编译器的手册页（手册）。从命令行输入：
man cc
这应该会打开一个手册页，告诉你很多关于你系统上编译器的事情。这可能会告诉您如何告诉编译器生成更多警告消息，这可以帮助您在运行程序之前找到错误。 （请注意，如果您在打开某些优化的情况下进行编译，则可能只会生成一些警告，因此即使您可能不想调试优化程序，您也可能需要通过优化编译它并打开额外警告，看看它们是否有效告诉你任何事情。）
你的Unix系统可能安装了某种类型的调试器。为C开发设置的大多数Linux机器都安装了gdb。 gdb可用于在调试模式下运行程序或分析核心文件。如果你有gdb，你可以：
gdb ./program
它会准备好运行你的程序。如果你这样做：
gdb ./program ./core
它的行为类似，只不过它就好像你在调试而你的程序崩溃了。从这个状态来看，你可以做的最快和最有帮助的事情是
(gdb) bt
此处(gdb)是提示符，bt是一个生成回溯的命令。这意味着一个调用堆栈，它显示了失败发生时程序所处的功能，以及调用该函数的函数，以及调用该函数的函数，以及直到第一个函数。这可能会令人困惑，因为它通常会将库函数显示为最近调用的函数，但这通常意味着您在导致问题的路上传递了一些不良数据。
gdb是一个庞大而复杂的程序，所以如果它在你的系统上，你应该花时间阅读它。
如果它不在您的系统上，那么您应该找出类似的工具。一些图形调试器（在IDE中或不在IDE中）充当命令行调试器的前端，有些甚至支持几个不同的命令行调试器，因此如果您能够使用其中一个图形调试器，您可能实际上不必担心关于使用什么实际后端命令行调试器。
答案 2 :(得分：8)
使用gdb。它是事实上的标准Unix C / C ++调试器，从版本7.0开始，它具有可逆调试功能（您可以及时倒退）。仅凭这些原因使其至少值得一试。
答案 3 :(得分：3)
我真的很喜欢Totalview。并行调试功能让我像我一样喜欢它。
答案 4 :(得分：2)
通常，gdb是一个优秀的调试器（虽然需要一些学习）。还有各种前端，有些带有GUI，例如DDD或cgdb。
如果您解释具体有问题，我们可以更好地推荐哪种调试器对您有所帮助。
答案 5 :(得分：0)
如上所述，gdb是一个出色的调试器。但是在linux终端中，使用gdb调试较大的项目要复杂得多。简单的原因是它完全是命令行界面。因此，我建议kdevelop以图形方式在内部使用gdb。这个调试工具非常轻松地帮助我调试了大型项目。如果您在使用此工具时需要任何帮助，请告诉我。