linux c调试的问题

Question

目前在开发linux下面的一个c项目，debug目前主要靠日志来定位问题。
想问问linux下有什么好的方法debug吗？定位问题。
比如突然process crash了，怎么知道是哪一句代码出问题的？

Answer 1

gdb的三种用法；
1.调试自运行的可只执行程序；
比如自己写的myProgrammer. 编译的过程加上-g标识符，调试通过以下方式启动：

gdb myProgrammer

2.调试coredump文件；
某个进程有bug，突然crash了，如果系统打开了core dump标志，则会留下coredump文件(eg:core.71818)：
调试core dump文件启动方式：

   gdb  myProgrammer  core.71818

3.调试服务程序；
某个进程myService正在运行中，将gdb挂上去调试方法：
1）找到这个进程的进程号pid：

   ps-fe| grep myService  

2) gdb挂上去后调试：

   gdb attach pid

关于gdb中通用调试命令的总结，请见《linux工具快速教程》gdb节：
http://linuxtools-rst.readthedocs.org/zh_CN/latest/tool/gdb.html

关于linux程序调试还有很多工具，比如pstack等等，详见程序调试：
http://linuxtools-rst.readthedocs.org/zh_CN/latest/advance/02_program_debug.html

附：需要进程crash后产生core dump文件，需要设置下系统：

1.core文件的生成开关和大小限制

1）使用ulimit -c命令可查看core文件的生成开关。若结果为0，则表示关闭了此功能，不会生成core文件。
ulimit -a ：查看全部
ulimit -n：查看可以打开的文件句柄数目；

2）打开core开关
使用ulimit -c filesize命令，可以限制core文件的大小（filesize的单位为blocks）。
若ulimit -c unlimited，则表示core文件的大小不受限制。如果生成的信息超过此大小，将会被裁剪，最终生成一个不完整的core文件。在调试此core文件的时候，gdb会提示错误。

Answer 2

编译的时候加上-g3或者-ggdb3，如果能捡到core文件，用gdb xx core，然后bt一下，回溯崩溃前的调用栈，多半可以定位到到底是执行到哪一部分发生了崩溃。

Answer 3

process crash 不是有coredump文件可以查看吗。。题主参考：UNIX 程序常见问题的分析方法
http://www.ibm.com/developerworks/cn/aix/library/1206_yudh_unixproblemsolve/

Answer 4

只有控制台,看一下 gdb
如果有界面的 codeblocks 配一配

Answer 5

linux调试必然用gdb啊

Answer 6

刚刚看linux编程看到gdb……这个可以调试的。