GDB

SIGBUS和SIGSEGV也许是我们在平时遇到的次数最多的两个内存错误信号。内存问题一直是最令我们头疼的事情，弄清楚两个信号的发生缘由对我们很好的理解程序的运行是大有裨益的。 我们来看两段程序： //testsigsegv.c int main() { char *pc = (char*)0×00001111; *pc = 17; } ...

大凡写程序者，都会遇到错误； 大凡写程序者也都知道两种错误处理的机制：传统的’错误码返回机制’和’面向对象语言引入的异常处理机制’。 ...

今天凌晨配合云南移动进行局数据全量升级，本来以为是件很轻松的活计，甚至不需要我动手的事情，结果却又是一次惨痛的教训啊。 这个活计其实真的很简单，就是将数据库中的旧数据全部删除，然后导入新的数据，由于数据量较大需要重启一次我们的系统。问题就在重启系统上。摆在我面前的就是"重启失败"，系统dump一个core文件。通过pstack和gdb查看如下： core ‘core’ of 7971: xxxxx -s fe647b38 t_splay (3a71b0, 229, 228, 3a7000, 3ca548, 8000000) + 14 fe6475ec realfree (3ca320, 741f4, 320974, fe6bc000, 0, 3209a5) + c8 fe647e5c cleanfree (0, 7, fe6c29bc, 1a8, 3a7008, 0) + 54 fe646f88 _malloc_unlocked (ea60, 0, ff13de50, fe6bc000, ff184ae6, 0) + f4 fe646e78 malloc (ea60, 3e8, 0, 2, f8e9dacb, 1) + 20 000fa330 我们一业务函数，暂叫A_func吧 (18, 186a0, ffbfe4b0, 30330000, 37, ff00) + 1fc ...

最近自己曾经辛苦耕耘过的两个项目同时上线，相关问题也就逐渐暴露出来。工作这两年多时间以后，使我有这样感觉：’测试永远都是不完备的’，有些问题只能在商用过程中发现，呵呵，明确一点啊我不是搞测试的:) ...

这几天以前曾经做过的一个项目上线测试了，果不其然，没有经过’战争洗礼’的产品就是靠不住，这不出了若干问题。害得我逃了半天课远程支持。 其中的一个问题很值得思考。其所在的模块并非是一个核心功能模块，而是一个提高系统Availability的一个功能模块，主要功能就是监视磁盘占用率。我们通过配置给出允许使用的磁盘空间大小(以M Byte为单位)，以及两个阈值，即当占用率达到多少的时候，Do A；达到多少的时候Do B。 ...

上午我们的一个实施组从现网发回来一封邮件，接到这种邮件一般都是报告问题的，果然不出所料，现场出现一个core，经过分析这是个由于线程函数参数存储位置不当造成的，从中我们可以总结出一些经验，以避免以后再犯。 ...

下午一同事发现代码中的一处问题，问题的现象是这样的：这位同事调用了一部门基础库函数，当使用32位编译后，程序正常运行；而当使用64位编译后，系统运行dump core。让这位同事奇怪的是他所修改的程序中还有其他模块也使用了同样的基础库函数，为什么偏偏他这块儿出错呢？恰恰该程序的其他模块是我写的。 ...

有一段时间没有写技术方面的东西了^_^。众所周知，GDB是Unix/Linux下调试程序的龙头老大，GDB功能强大，我们在平时多使用其一些最基本的功能，而且一般调试的都是单进程的程序。最近一个项目中的问题让我接触如何使用GDB调试多进程程序，更确切的是说调试调用fork的多进程程序。 使用GDB最好的文档就是其名为’Debugging with GDB‘的参考手册。手册中有一小章节提到了如何调试多进程程序。一般情况下，如果被gdb调试的程序中调用fork派生出一个新的子进程，这时gdb调试的仍然还是父进程，其子进程的执行不被理会。如果之前你在子进程的执行routine上设置了断点，那么当子进程执行到那个断点时，子进程会因为收到一个SIGTRAP信号而自行终止，除非你在子进程中拦截了该信号。 ...

不得不承认上次关于栈桢和栈操作写得有些笼统，这里做一次“补充”，美名其曰：“复习”。 下面的这个例子几乎就能覆盖所有的栈操作相关的内容了。 void dummy() { int i = 12; int j = 13; char c = ‘a’; } ...