I'm trying to see if a (batch, conventional z/OS, C++, 31-bit, V1R13)
program has memory leaks. After reading "Diagnosing storage leak problems"
in the LE debugging guide, I run the program with

//CEEOPTS DD  *  
      HEAPCHK(ON,1,0,10,10,1024,0) 
/*                               

I get the following on CEEDUMP on termination:

Heap Storage Diagnostics                                           
  Stg Addr  ID        Length      Entry         E Addr    E Offset 
  15C55158  00000000  00000828    CEEV#GH       1542C620  +00000000
                                  realloc_name_buffer              
                                                157FC750  +00000074
                                  setlocale     157FD348  +0000016C
                                  tzset         157751C0  +0000066C
                                  _cinit        156DDF70  +000032C0
                                  CEEZINV       15462490  +00000D18
                                  main          15100160  -EAF07E30
  15C55CD8  00000000  00000040    CEEV#GH       1542C620  +00000000
                                  dllinit       155BE410  +00000100
                                  CEEZIDT       15461308  +0000089C
                                  main          15100160  -EAF07E94

I guess that indicates that there are two un-freed heap areas, one 0x828
long and one 0x40 long -- is that right? They look like "system" areas
allocated at startup, so they probably are not "problem" leaks, right?

But just to be sure, I add the following intentional memory leak to my
program:

    char *foo = new char[99];  

I run the program again. I get *exactly* the same storage diagnostics. So
now I have no idea whether HEAPCHK is actually reporting storage leaks or
not.

Anyone have any tips? Am I doing something wrong?

Thanks,
Charles 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to