《关于coredump的心得.docxVIP

从接触unix开始就一直听到和遇到core dump，特别是刚学着使用C语言在编写程序的时候，core dump更是时不时就会不请自来。记得当时刚写应用的时候，提交程序时最怕的就是在运行过程时遇到core dump，对于BOSS核心系统，特别是使用静态应用进程，如果一个相对频繁一点的交易导致core dump，那么毫无疑问，除了赶紧定位错误改程序外，重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core dump的，就是程序中一个小小的未注意到或者未测试到的一个疏忽。 ? 虽然常常遇到core dump，不过很长时间内，都是出于知道这个名字，知道它导致的后果，知道一部分导致它出现的原因，其他的就都不甚了了了。说起来，就是自己太懒了，懒得看书......少壮不努力啊。看过一则统计，说60岁以上的老人，超过70%都后悔少壮不努力，不知统计的数据能否反映整个社会的情况。不过总的来说，这句古话还是有些道理的。大家不要学我。哈哈? core dump，翻译过来讲，就是核心转储。大致上就是指，如果由于应用错误，如浮点异常、指令异常等，操作系统将会转入内核的异常处理，向对应的进程发送特定的信号（SIGNAL），如果进程中没有对这些信号进行处理，就会转入默认的处理，core dump就是其中的一种。如果进程core dump，系统将会终止该进程，同时系统会产生core文件，以供调试使用。这个core文件其实就是内存的映像，即进程执行的时候内存的内容，也就是所谓的core dump。平常大家说某某进程core dump了，其实主要的意思就是说：某某进程因为错误而被系统自动终止了。? unix上提供了gdb和pstack工具可以对core dump进行调试，协助定位引起core dump的代码。最普通的语法是：?gdb应用名 core文件， 然后使用where命令来显示调试信息pstack core ，然后使用where命令来显示调试信息一般情况下，使用后打印出当时程序被中止时候的栈内存信息，有很多中形式，有些比较好的core选项甚至可以打印出该程序core之前的输入，我见过吉林的就是，悲剧的安徽就不是，只是打印出来core之前的输入的内存地址，除了主机之外，谁tmd知道那块内存里面放的是什么东西!因为这是一个栈信息，所以这个信息是颠倒的，从下至上的。最上面的一个函数应该是被程序最后调用并且被系统中止处的。从调试信息一般可以定位到core的地方，但是很多时候也不一定，因为有些时候core的真正原因并不是被中断的地方。准确的讲，他是“被”中断的。一般来讲，根据工作中遇到的情况，gdb还是能够比较轻松的根据提示的内容来定位代码的。不过也有一些特殊情况时gdb显示的调试信息过于模糊或者不直观，这个时候就只能根据经验来逐步定位了。有时定位起来会耗用相当长的时间。遇到这种情况时，使用日志文件，通过在代码中穿插多个写log的语句，也可以协助发现。因为进程core dump时，日志当然也中断了，根据日志在哪个代码行之后或之前中止了，可以有效缩小寻找的范围。甚至，在有些情况下，使用日志定位是唯一简便的方法了。造成程序coredump的原因很多，这里根据以往的经验总结一下：1 内存访问越界? a) 由于使用错误的下标，导致数组访问越界，比如你定义了Int A[11];你却使用A[12]=2;这种情况现在不常见了，好多编译器都会检测到，所以一般首先会出现的变异阶段。属于比较弱智的。b) 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符。比如char str[22];结果str[21]它不是’\0’,即字符结束符，就会导致系统误认为该字符数组没有结束，继续往后访问，结果造成内存溢出。这种情况比较常见，一般应该注意。而在PROC中也会出现这种错误，不过sql会对此种情况定义了一个相应的错误码，具体值我忘记了，中文意思就是没有找到字符串结束符。不信你可以试试Char Sqlstr[10];Sprint(Sqlstr,”select id_NO　from ur_user_info where phone_No=’XXXX’”);EXEC SQL EXECUTEBEGINEXECUTE IMMEDIATE : Sqlstr INTO :lIDNO END;END-EXEC;因为你的绑定变量Sqlstr只定义了10位，oracle在解析时候会在地10处找结束符，如果没有找到，就报错。 c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf,