No, I don't instrument at all. I use my knowledge of the LE heap implementation (see the presentation mentioned below) to store a map of all allocated and free areas at a given time (area adresses and lengths) and then - some microseconds later - I compare that with the new image then. Then I build a delta listing which shows all the areas that have changed in the meantime, that is, which have been allocated and not freed.
If you call this before and after a critical function, you will see exactly what areas are left "unfreed" by this function. This proved to be very helpful in our environment, especially if the critical function is written by another team. (I don't need to "instrument" the functions of the foreign team). Kind regards Bernd -----Original-Nachricht----- Betreff: Re: COBOL 2014 dynamic capacity tables Datum: 2016-08-09T13:53:15+0200 Von: "David Crayford" <[email protected]> An: "[email protected]" <[email protected]> I use the HEAPCHK(ON,1,0,10,10) LE runtime option to find my memory leaks. How is your instrumentation different? I assume you wrap malloc()/free() calls? On 9/08/2016 1:50 AM, Bernd Oppolzer wrote: > IMO there is no need to create additional heaps > to support dynamic tables in COBOL. > > I did some research some days ago on the LE heap > implementation and found an old IBM presentation (from 2005) on > this topic called "Stacks and Heaps" (you will find it using > Google, the full title reads something like "Stacks are easy, > heaps are fun"). There are COBOL examples included, which > use the LE functions CEEGTST (get storage) and CEEFRST > (free storage) - I hope, I recall the names correctly. > > Based on these functions (which are malloc and free, after all), > you could do all sorts of dynamic allocations from COBOL, using > the normal LE "user heap", which is sufficient, IMO. > > BTW: I wrote some functions in the last few days, which dumps all > the allocated heap areas and - more interesting - they write reports, > how the heap has changed since the last call. This is very interesting > ... > if you have a function that you think that does not free its heap areas > properly, you can call this heap report function before and after > this function call and find out by looking at the so called heap delta > listing. > > If you are interested, feel free to contact me offline. > > Kind regards > > Bernd > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
