程序coredump原因
程序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,看到:
/session
Dec 1 09:56:39 cos-vhost kernel: Out of memory: Kill process 11000 (session) score 535 or sacrifice child
Dec 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.log
T: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<class typeEncoder,class str1, class str2>static size_tconvert( const str1 & strSrc, str2 & strTar )
{
strTar = str2(); //当pLongProp为空的时候，在其调用的函数里面构造对象。
return append<typeEncoder>(strSrc,strTar);
}