程序coredump原因，

1，

9) SIGKILL
用来立即结束程序的运行. 本信号不能被阻塞、处理和忽略。如果管理员发现某个进程终止不了，可尝试发送这个信号。

如果是这个信号，那么是系统杀死，捉不了core文件。

例如：

经查看，程序coredump时无core文件生成，查看coremail.log，sessionsvr是被信号杀死，非自己coredump

(2015-11-30 10:08:54)(26673) Process 25428(session) stop with state 9: The process was terminated with a signal(2015-11-30 10:08:54)(26673) The number of the signal that caused the termination of the child process : 9(2015-11-30 10:08:57)(26673) Starting session(2015-11-30 10:08:57)(26673) session Server(pid:26388) Started!

查看系统message日志。

vi /var/log/messages搜索session,看到:/sessionDec 1 09:56:39 cos-vhost kernel: Out of memory: Kill process 11000 (session) score 535 or sacrifice childDec 1 09:56:39 cos-vhost kernel: Killed process 11000, UID 501, (session) total-vm:6558976kB, anon-rss:4841180kB, file-rss:136kB

可得是系统将程序杀死。

查看session日志，

与sessionsvr的日志相吻合：[root@cos-vhost ~]# grep begin /home/coremail/logs/session.logT:2572687136(09:56:42)[System.Process:Info] Application begin to work.

多次检查session日志与messages日志想比对，时间均吻合。

得出之前的重启的原因均是sessiosvr的内存过高被系统杀死

2，非法内存访问，需要valgrind测试一下哪里非法访问。

11) SIGSEGV
试图访问未分配给自己的内存, 或试图往没有写权限的内存地址写数据.

可以捉下core文件

非法内存访问例子:

UD_DATA_LOG_WITH_UID( m_ses ).add(UD_DATA_LOG_CMD, UD_CMD_SETMSGINFO).add( UD_DATA_LOG_SUBJ, m_ses.env().convertDisplay( pLongProp->GetSubject(), strConvertDisplay) ).add(UD_DATA_LOG_FROM, m_ses.env().convertDisplay( pLongProp->GetFrom(), strConvertDisplay2) ).add(UD_DATA_LOG_TO, m_ses.env().convertDisplay( pLongProp->GetTo(), strConvertDisplayTo) ).add(UD_DATA_LOG_MSG_ID, baseProp.GetMsgID() ).add("read", boChangeRead?"1":"0").msg("");

原因： 当pLongProp为空的时候，在其调用的函数里面构造对象。

template
     
      static size_tconvert( const str1 & strSrc, str2 & strTar ){ strTar = str2(); //当pLongProp为空的时候，在其调用的函数里面构造对象。 return append
      
       (strSrc,strTar); }