写文件造成PgSp 持续增长
时间：2010-10-13 来源：snailshen
一个话单分拣程序，发现运行一段时间就core掉
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:"<<sFile<<" error!!!"<<endl; oFstm.close(); return; } oFstm<<sdata; 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 一直在增长，确实内存泄露了 明天改造程序不要频繁写文件。 写这个日志。留个记号。
频繁的写文件在一个目录下的几个子目录下，目前看是造成了内存泄露。当到一定条件时，程序崩溃了。现在修改了程序，一个源文件分析之后再集中写文件。避免了频繁的打开，写，关闭操作。目前未出现内存泄露。
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:"<<sFile<<" error!!!"<<endl; oFstm.close(); return; } oFstm<<sdata; 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 一直在增长，确实内存泄露了 明天改造程序不要频繁写文件。 写这个日志。留个记号。
频繁的写文件在一个目录下的几个子目录下，目前看是造成了内存泄露。当到一定条件时，程序崩溃了。现在修改了程序，一个源文件分析之后再集中写文件。避免了频繁的打开，写，关闭操作。目前未出现内存泄露。
相关阅读 更多 +
