C语言 C 和 C++ 的最佳调试工具

Best debugging tool for C and C++

提问by Sachin Chourasiya

I am working on C/C++ on UNIX and have often seen core files. Many times the core files are difficult to debug to find the actual cause of core or the segmentation fault. Could you please suggest me an efficient debugger?

我在 UNIX 上使用 C/C++ 并且经常看到核心文件。很多时候core文件很难调试，找到core或者segmentation错误的真正原因。你能给我推荐一个高效的调试器吗？

采纳答案by nategoose

I think most C compilers on most flavors of *nix support -gto include debugging symbols within the object files, so if you do:

我认为大多数 *nix 版本的大多数 C 编译器都支持-g在目标文件中包含调试符号，所以如果你这样做：

cc -g -c file1.c
cc -g -c file2.c
cc -g file1.o file2.o -o program
./program

Then when you run program if it crashes it should produce a more easily debugged core file. The first two lines just compile source files (producing .o files), the third line tells the compiler to call the linker to link the source files into an executable (passing -ghere may not actually do anything if the linker does not have to do anything special to produce an executable with debugging symbols, but it should not hurt anything), and the last line runs the program. You should make sure that you do not tell the compiler to do optimizations when you are trying to debug (unless you find that it does not have errors unless optimizations are turned on) because optimizations typically make the more difficult to follow.

然后当你运行程序时，如果它崩溃，它应该会生成一个更容易调试的核心文件。前两行只是编译源文件（生成 .o 文件），第三行告诉编译器调用链接器将源文件链接到可执行文件中（-g如果链接器不需要做任何事情，传递到这里实际上可能不会做任何事情）特别是生成带有调试符号的可执行文件，但它不应该伤害任何东西），最后一行运行程序。您应该确保在尝试调试时不告诉编译器进行优化（除非您发现它没有错误，除非打开优化），因为优化通常会使更难以遵循。

Since I don't know what platform you are on or what tools you have available (or really even what C compiler you are using) so it is difficult to give more specific advice. You should read the man page (manual) for your complier. From the command line type:

由于我不知道您在哪个平台上或您有哪些可用的工具（或者甚至您正在使用什么 C 编译器），因此很难提供更具体的建议。您应该阅读编译器的手册页（手册）。从命令行输入：

man cc

And that should bring up a manual page that tells you lots of things about the compiler on your system. This may tell you how to tell the compiler to produce more warning messages, which could help you find your errors before even running your programs. (note that some warnings may only be produced if you compile with certain optimizations turned on, so even though you probably won't want to debug the optimized program you may want to compile it with optimizations and extra warnings turned on just to see if they tell you anything).

这应该会打开一个手册页，告诉您有关系统上编译器的许多信息。这可能会告诉您如何告诉编译器生成更多警告消息，这可以帮助您在运行程序之前找到错误。（请注意，只有在打开某些优化的情况下编译时才会产生某些警告，因此即使您可能不想调试优化的程序，您也可能希望在打开优化和额外警告的情况下编译它，只是为了看看它们是否什么都告诉你）。

Your Unix system probably has some type of debugger installed. Most Linux machines set up for C development have gdbinstalled. gdbcan be used to run your program in debug mode or to analyze a core file. If you have gdb you can:

您的 Unix 系统可能安装了某种类型的调试器。大多数为 C 开发设置的 Linux 机器都已gdb安装。 gdb可用于在调试模式下运行程序或分析核心文件。如果你有 gdb，你可以：

gdb ./program

it will start up ready to run your program. If you do:

它将启动准备运行您的程序。如果你这样做：

gdb ./program ./core

it will behave similarly except that it will be as though you were debugging and your program just crashed. From this state the quickest and most helpful thing you can do is to

它的行为与此类似，只是它就像您正在调试并且您的程序刚刚崩溃一样。在这种状态下，你能做的最快、最有帮助的事情就是

(gdb) bt

Here (gdb)is the prompt and btis a command that says to produce a back-trace. That means a call stack, which shows what function the program was in when the failure happened, and what function called that function, and what function called that function, and on and on up to the first function. This can be confusing because it will often show library functions as the most recent called, but this usually means that you have passed in some bad data somewhere along the way that is causing the problem.

这(gdb)是提示，bt是一个表示生成回溯的命令。这意味着一个调用堆栈，它显示了失败发生时程序所在的函数，哪个函数调用了那个函数，哪个函数调用了那个函数，一直到第一个函数。这可能会令人困惑，因为它通常会将库函数显示为最近调用的函数，但这通常意味着您在导致问题的过程中在某处传递了一些错误数据。

gdbis a large and complex program so if it is on your system you should take the time to read up on it.

gdb是一个庞大而复杂的程序，所以如果它在您的系统上，您应该花时间阅读它。

If it is not on your system then you should find out what similar tools are. Some of the graphical debuggers (either within an IDE or not) act as front ends to command line debuggers and some even support several different command line debuggers, so if you are able to use one of the graphical debuggers you may not actually have to worry about what actual back end command line debugger is being used.

如果它不在您的系统上，那么您应该找出类似的工具。一些图形调试器（无论是否在 IDE 中）充当命令行调试器的前端，有些甚至支持几种不同的命令行调试器，因此如果您能够使用其中一个图形调试器，您实际上不必担心关于正在使用的实际后端命令行调试器。

回答by Tilman Vogel

For segmentation faults, memory leaks, uninitialized data and such, running your program through valgrindis always a good idea. If you are especially interested in memory leaks, the option "--leak-check=full" pays off.

对于分段错误、内存泄漏、未初始化的数据等，通过valgrind运行程序始终是一个好主意。如果您对内存泄漏特别感兴趣，那么选项“--leak-check=full”是值得的。

And yes, learn gdb. It takes a little time, but it's worth it.

是的，学习gdb。这需要一点时间，但这是值得的。

回答by darioo

Use gdb. It is the defacto standard Unix C/C++ debugger and as of version 7.0 has reversible debugging features (you can go backwards in time). These reasons alone make it at least worthwhile to check it out.

使用gdb。它是事实上的标准 Unix C/C++ 调试器，从 7.0 版开始，它具有可逆的调试功能（您可以及时倒退）。仅这些原因就至少值得检查一下。

回答by Derek

I really like Totalview. The parallel debugging features are what make me like it as much as I do.

我真的很喜欢 Totalview。并行调试功能让我和我一样喜欢它。

回答by sleske

Generally, gdbis an excellent debugger (though it takes a bit to learn). There are also various frontends, some with a GUI, such as DDD or cgdb.

一般来说，gdb是一个优秀的调试器（虽然需要一些学习）。还有各种前端，有些带有 GUI，例如 DDD 或 cgdb。

If you explain where specifically you are having trouble, we may be able to better recommend which debugger will help you most.

如果您具体说明您遇到问题的地方，我们可能能够更好地推荐哪个调试器最能帮助您。

回答by nhkrishna

As suggested above gdb is an excellent debugger. But in the linux terminal debugging larger projects with gdb is little more complex. Simple reason is it is completely command line interface. So i would suggest kdevelopwhich internally uses the gdb in graphical manner. This debugging tool helped me a lot in debugging my big projects in very easy manner. Let me know if you need any help in using this tool.

如上所述，gdb 是一个出色的调试器。但是在 linux 终端中使用 gdb 调试较大的项目要复杂一些。原因很简单，它完全是命令行界面。所以我建议kdevelop在内部以图形方式使用 gdb。这个调试工具帮助我以非常简单的方式调试我的大项目。如果您在使用此工具时需要任何帮助，请告诉我。