Re: memory leak doing gsk_environment_open()
> 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. You can control that with the FREE option on the HEAP LE runtime option. See z/OS 2.2.0>z/OS Language Environment>z/OS Language Environment Programming Reference>Language Environment runtime options>Using the Language Environment runtime options>HEAP. http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ceea300/clheap.htm?lang=en-us "KEEP Specifies that an increment to user heap storage is not released when the last of the storage within that increment is freed. FREE Specifies that an increment to user heap storage is released when the last of the storage within that increment is freed." KEEP is the default. -Carl -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can an assembler routine return a 64-bit value to C?
Does the HGPR compiler option make any difference? z/OS 2.2.0>z/OS XL C/C++>z/OS XL C/C++ User's Guide>Compiler options>Description of compiler options>HGPR | NOHGPR Purpose Enables the compiler to exploit 64-bit General Purpose Registers (GPRs) in 32-bit programs targeting z/Architecture® hardware. When the HGPR compiler option is in effect, the compiler can exploit 64-bit GPRs in the generated code. The compiler will take advantage of this permission when the code generation condition is appropriate. When the NOHGPR and ILP32 compiler options are in effect, the compiler cannot exploit 64-bit GPRs in the generated code. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
On Thu, 19 Feb 2015 08:18:05 -0600, Ze'ev Atlas zatl...@yahoo.com wrote: I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. I thought so when I was introduced to C in the late nineteen eighties and I did not find any reason to change my mind ever since. You can always use int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t and friends in /usr/include/stdint.h. ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: In C++ any way to get traceback info in a catch()?
How about using set_new_handler() in your main() to register a new_handler() that does a ctrace() followed by a throw(std::bad_alloc)? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: In C++ any way to get traceback info in a catch()?
On Fri, 23 Jan 2015 10:50:50 -0800, Charles Mills charl...@mcn.org wrote: Works like a champ! That is exactly what David Crayford (thank you, David!) suggested off-line. I followed the spirit of this, but did things somewhat differently. In my new handler, I - Put out a diagnostic message - Call CEE3DMP - Call my existing clean-up-and-terminate routine. It seems to me that you have to be careful not to do too much in your new handler, because, depending on the size of the new() that failed, you might have very little HEAP or STACK space to work with. One way around that might be to new() a reserve buffer before calling set_new_handler() and then freeing that reserve buffer in your new handler. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: In C++ any way to get traceback info in a catch()?
On Fri, 23 Jan 2015 11:26:06 -0800, Charles Mills charl...@mcn.org wrote: In my test it is one 6.3MB new that fails. So I presumably have lots of spare heap; just not 6.3MB. If the failure were due to a loop that did lots of tiny new's then that would not be the case. If the loop involved recursion I might be out of stack. One of the major chores my terminate routine does is lots and lots of delete's, so that would presumably free up heap. ... On Fri, 23 Jan 2015 13:11:37 -0600, Carl Kugler carl.kug...@infoprint.com wrote: It seems to me that you have to be careful not to do too much in your new handler, because, depending on the size of the new() that failed, you might have very little HEAP or STACK space to work with. One way around that might be to new() a reserve buffer before calling set_new_handler() and then freeing that reserve buffer in your new handler. Actually, thinking about it some more, I shouldn't have said depending on the size of the new() that failed. It would depend on the history of the heap and stack and their sizes, so it's really a matter of luck whether there's enough space left for your cleanup processing when new() fails, unless your cleanup processing doesn't need any space, or you reserve some. You can trace heap allocations with the LE MEMCHECK VHM memory leak analysis tool (https://www-304.ibm.com/support/knowledgecenter/SSB27U_5.4.0/com.ibm.zos.r9.ceea100/memcheck.htm%23memcheck?lang=en-us), so you might be able to use that to determine how much heap your cleanup processing needs. Then there's stack... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
