Try the following runtime option HEAPCHK(ON,1,0,10,10). It will produce
a dump with a trace of all memory allocations that have no free.
However, it's not unusual for APIs to allocate memory once and store the
pointer in WSA, kind of like a singleton. That's how the standard stream
libraries work and it may be the case with system SSL. If memory is not
increasing every time you call gsk_environment_open() then I would
suggest it may be working as designed.
On 3/02/2016 7:33 AM, Janet Graff wrote:
I have run RPTSTG on the application several times in the past and tuned
things. I can do this again. However I can see this leak every time I run
through an HTTP creation of socket, request, and socket termination. Which is
what makes me believe that either the memory isn't cleaned up or the sequence
of functions I am calling is incorrect.
I see the memory usage on every gsk_environment_open() but I never see the
memory freed on any of the close or shutdown calls.
This is indeed C.
Janet
---- replied to message ---
Janet,
I assume this is a C application by the long and lower-case function names you mentioned.
Have you run it with the LE RPTSTG option turned on? Maybe your HEAP parameters cause
LE to request that 1M storage as a secondary heap chunk because the "gsk_*"
routines need some heap storage, and I do not believe that heap chunks are freed until
termination of the enclave, even if there are no current storage allocations in the
chunk(s). RPTSTG output may help you tune the initial heap size so that secondary chunks
are not needed.
Just a thought.
Peter
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
