core 信息如下：
intf%dbx split_cdr.bin core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...
IOT/Abort trap in pthread_kill at 0x90000000036b89c ($t5)
0x90000000036b89c (pthread_kill+0x88) e8410028 ld r2,0x28(r1)
(dbx) where
pthread_kill(??, ??) at 0x90000000036b89c
_p_raise(??) at 0x90000000036b2b0
raise.raise(??) at 0x900000000063478
abort() at 0x90000000008eaac
myabort__3stdFv() at 0x9000000003a6fb4
terminate__3stdFv() at 0x9000000003a5320
terminate__Fv() at 0x9000000003a67ac
(dbx)
经过查看把写文件函数注销掉。程序跑一个晚上也没有事情。
写文件函数：
/*string sFile = sfilename;
ofstream oFstm(sFile.c_str(),ios::app);
if(!oFstm){
cout<<"open file:"<
oFstm.close();
return;
}
oFstm<
oFstm.close();*/
/*string sfile = sfilename;
int ifile = open(sfile.c_str(),O_WRONLY|O_CREAT|O_APPEND,00644);
if(ifile ==-1){
printf("open file error\n");
return;
}
write(ifile,sdata.c_str(),sdata.size());
close(ifile);*/
string sfile = sfilename;
FILE * pFile = fopen(sfilename.c_str(),"a+");
if(NULL==pFile){
printf("open file:[%s],error!!!\n",sfilename.c_str());
return;
}
fprintf(pFile,"%s",sdata.c_str());
fflush(pFile);
fclose(pFile);
------通过topas查看，如果住下掉写文件的函数topas 的PgSp值一直不会变化，如果加上写文件发现这个值一直缓慢增加，并且用c的函数比ofstream增长慢。
Name PID CPU% PgSp Owner
split_cd 786548 2.7 8.7 intf
难道是内存泄露吗？
---------------
用svmon -P 看
svmon -P 270582
-------------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB
270582 split_cdr.bin 38360 8441 28 29451 Y Y N
PageSize Inuse Pin Pgsp Virtual
s 4 KB 26040 8393 28 17131
m 64 KB 770 3 0 770
Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
0 0 work kernel segment s 13236 8390 0 13246
870b0 90000000 work shared library text m 765 0 0 765
64dee - clnt /dev/lv_jk_data01:12456 s 8373 0 - -
8001 9ffffffd work shared library s 1672 0 2 1674
88193 90020014 work shared library s 1106 0 26 1119
c80be 11 work text data BSS heap s 851 0 0 851
f4135 10 clnt text data BSS heap, s 547 0 - -
/dev/lv_jk_data01:12463
dc6dd 9001000a work shared library data s 138 0 0 138
1fd91 f00000002 work process private m 5 3 0 5
efcef 80020014 work USLA heap s 51 0 0 51
30026 9ffffffe work shared library s 33 0 0 33
182 9fffffff clnt USLA text,/dev/hd2:2190 s 14 0 - -
50619 - work s 11 3 0 11
cc7df 8fffffff work private load data s 5 0 0 5
67d7e ffffffff work application stack s 3 0 0 3
64c6a fffffffd work application stack s 0 0 0 0
32b00 fffffffc work application stack s 0 0 0 0
4c82f fffffffe work application stack s 0 0 0 0
其中 c80be 11 work text data BSS heap 一直在增长，确实内存泄露了
明天改造程序不要频繁写文件。
写这个日志。留个记号。频繁的写文件在一个目录下的几个子目录下，目前看是造成了内存泄露。当到一定条件时，程序崩溃了。现在修改了程序，一个源文件分析之后再集中写文件。避免了频繁的打开，写，关闭操作。目前未出现内存泄露。