写文件造成PgSp 持续增长

一个话单分拣程序，发现运行一段时间就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:"<

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  一直在增长，确实内存泄露了

明天改造程序不要频繁写文件。

写这个日志。留个记号。

频繁的写文件在一个目录下的几个子目录下，目前看是造成了内存泄露。当到一定条件时，程序崩溃了。现在修改了程序，一个源文件分析之后再集中写文件。避免了频繁的打开，写，关闭操作。目前未出现内存泄露。

阅读(3114) | 评论(3) | 转发(0) |

0

上一篇：信号量

下一篇：memset