No, no, I am not trying to improve a program that is using too much memory. I am trying to write recovery code that will help diagnose future allocation failures, whatever their cause.
LE provides leak analysis tools and I use them. I know where the storage is going: <g> static const unsigned int size_to_allocate = 5000; for ( int i = 0; i < INT_MAX; i++ ) char *foo = new char[size_to_allocate]; Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Thursday, October 06, 2016 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CEEDUMP possible following 'new' failure Some suggestions: - try REPORT (LE option) to see where the storage is used (below, above, User heap, LE below- or anyheap) and how much storage is used before you get in trouble; does it depend from the amount of input data? REPORT will also show if you can do any better by playing with the LE options. - if it's not an easy case (storage acquired below, but should be above / any), there will be some processing which acquires storage and does not release it; you will have to identify that processing and repair it. - There are some tools on the market which allow you to find program parts which do such things (for example: CEL4MCHK, that is: LE memory checking heap manager) - I wrote a routine that takes some sort of snapshot of the heap at a certain point in time, and then again later, and then it compares the two snapshots and shows the areas that have been acquired in the meantime and not freed. I was very successful in finding memory leaks with this tool at my current customer's ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
