Janet, I *think* there may be a misunderstanding here. Here is my simplified *guess* of how C memory management works. Credit where credit is due: I am expanding on a point made by Peter Farley.
When your C program starts up, the runtime uses STORAGE OBTAIN to allocate a heap (several heaps, and a stack -- I said this was simplified). The runtime uses that heap to satisfy malloc() and new requests. If a request exceeds the remaining heap, the runtime issues a STORAGE OBTAIN for more storage. I suspect that is the 1MB increase in allocated storage that you are seeing. (BTW you can tune the initial heap size and the additional increment size with #pragma statements in your C.) Now, here is where I think your analysis may be going wrong: if the requested storage that caused the heap to expand gets returned with a free() or delete I do not believe the C runtime issues a STORAGE RELEASE for the additional increment of heap: it keeps it around in anticipation of future malloc() or new requests. It does not RELEASE the heap storage until the enclave ends. An analysis tool such as Omegamon or TMON will still show the storage as in use -- even though it is not really in use. It is in use from z/OS's point of view but not from the C library's point of view. If the allocated storage does not continue to increase (as David suggests) and if HEAPCHK does not show "lots" of unreleased storage at the end of your program, then I think you are good. Lots? Well, in my experience, exactly two unreturned allocations, one of 0x828 and one of 0x40 bytes, is normal. WARNING: HEAPCHK may make your program unbelievably slow, slow enough sometimes to expose timing issues in the code. My product, which normally completes initialization in about five seconds, instead takes about five minutes to come up, and nearly as long to come down. The only way I know of that this "no RELEASE" strategy could be a problem would be that the storage is not available for other non-C-library allocations, such as VSAM or DB2 buffers or some other non-C program that was sharing the address space. HTH Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Janet Graff Sent: Tuesday, February 02, 2016 2:24 PM To: [email protected] Subject: memory leak doing gsk_environment_open() I have a long running STC that does an HTTP sequence using secure sockets. I can monitor the memory usage throughout my calls. I note that my above the line storage shows a 1M increase after the gsk_environement_open(). That memory is not freed after the gsk_environment_shutdown(), gsk_environment_close() or any of the other APIs that close the socket. Has anyone else noticed this? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
