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 site.
(The culprit was
a PL/1 program, BTW, but it could have been C++, too ... the tool finds
them all).
If you are interested to know more about this, contact me offline.
Kind regards
Bernd
Am 06.10.2016 um 17:27 schrieb Charles Mills:
I have been wrestling with the issue of recovery from a failure of 'new'
(kind of like a GETMAIN for those of you who are not C people; just like
malloc() for those of you who are C but not C++ people) in XLC/LE C++ code.
(Yes, I know, the right answer is "don't do too many 'new's" but this is
error recovery code. Stuff happens, or IBM would not have invented ESTAE.
"More region size" is not the answer -- this is an intentional test of
storage exhaustion. More storage would just make it slower to fail <g>.)
First I got past the non-standard behavior of XLC in that rather than
blowing up per the standard, XLC just returns NULL (0) for a failed new. Got
the LANGLVL(NEWEXCP) in place.
So I am catching 'new' exceptions. The next problem was that it was
impossible to do anything meaningful after catching the 'new' exception
because storage was exhausted. So I read somewhere that one had to specify
#pragma RUNOPTS( STORAGE(,,,32K) ) to reserve some storage for the storage
exhaustion case. I specified 48K just to be on the safe side. This made
things better: I go through my error recovery, clean things up, and end
gracefully.
The remaining problem is that I am not getting any diagnostic information,
in other words, exactly *which* new failed -- which will of course make any
bug of this sort in the field hard to find. I call CEEDUMP to get a call
trace and it produces an *empty* four-line dataset. On the console I get
IEW4000I FETCH FOR MODULE CEEMENU3 FROM DDNAME *VLF* FAILED BECAUSE
INSUFFICIENT STORAGE WAS AVAILABLE.
CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEMENU3, RETURN CODE 24, REASON
CODE 26080021, DDNAME *LNKLST*
Any suggestions?
Charles
----------------------------------------------------------------------
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
