Re: [Plplot-devel] First proof-of-concept versions of PLplot "memory allocation" and "exception handling" topics

[Phil R. <p.d...@gm...>]

Hi Alan
I have sorted the issue with example 8. It turned out I had put some
plmalloc calls in there and forgotten about them.

Attached is a new patch series in a tarball. I don't see a huge need
to keep two separate branches any more. In fact I just tried to
disentangle my latest few commits into two branches using git rebase
-i and endured a whole world of pain. So I won't be returning to the
separate memory allocation functions branch any more. In the attached
patch series, patches 1-11 just have memory allocation functions.
After applying just these patches you should have source that builds
and runs, with the new functions defined but not used. patches 12 and
onward introduce the PLTRY, PLCATCH and PLENDTRY blocks and add them
into the API calls in plcore.c, plcont.c and plvpor.c. I have pretty
well tested plcont.c calls, but not plcore or plvpor calls.

You asked why every API call required a PLTRY block. You are correct
that actually they don't. Every API call that may result in a call to
plexit needs a PLTRY block. However, if we just have a policy that
every API call must have a PLTRY block then it makes it easy to ensure
nothing gets missed. But perhaps this is overkill. A number of
functions in plcore.c, particularly the "get" type ones are very
simple and would never call plexit. I'm happy to take advice on where
the balance should lie?

One other issue at the moment. I currently output a warning when
plfree is called on a pointer that is not being managed by the
PLStream. At present this will include all plfree calls made in
plend/plend1 and can include memory allocated by the contour routines.
The reason for this is due to the following chain of events
1) These bits of memory get allocated by plalloc in an API call
somewhere (e.g cmap0).
2) On exit from the API call plfreeall gets called
3) plfreeall spots the allocated memory that wasn't freed and checks
all the pointers that belong to the PLStream
4) It finds that the pointers belong to PLStream and need to not be
freed. It therefore stops tracking them.
5) In plend1 plfree is called on the pointer. plfree cannot see the
pointer in the list of tracked pointers so issues a warning.

There are a few options for dealing with this, but I haven't decided
which to use. For now my apologies for the list of warnings.

Thoughts welcome as ever.

Phil

On 17 July 2017 at 23:07, Alan W. Irwin <ir...@be...> wrote:
> On 2017-07-17 14:59-0700 Alan W. Irwin wrote:
>
>> With regard to testing the above memory_allocation2, I repeated the
>> same test as before (used the -DVALGRIND_ALL_TESTS=ON cmake option,
>> built the test_c_psc target, and checked for any imperfect valgrind
>> reports).  Examples 00 through 07 were fine, but example 08 segfaulted.
>> I have attached the associated valgrind report to help you to debug
>> this issue.
>
>
> Oops!  This time I really do attach that valgrind log.
>
>
> Alan
>
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________