[Plplot-devel] Third proof of concept for the "exception handling" topic -- Further discussion

[Alan W. I. <ir...@be...>]

Hi Phil:

Here is further discussion of what you have said as opposed to the
error report I sent you in my previous post concerning your 3rd
iteration.

Do keep in mind the possibility for the future that the memory
allocation part of your commits are worthwhile in their own right and
could be finished and landed on master much sooner than the rest of
your commits that are concerned with implementation of C exception
handling and use of that for handling our errors.

I suggested in my big e-mail to you early this week (Mon, 17 Jul 2017
14:59:00 -0700 (PDT)) concerning your second iteration a method of doing
this using a list of plstream heap pointers.  Please respond to that
suggestion.

Also please respond to my suggestion (with appropriate code changes
while I handle the CMake part) in that e-mail concerning

#define PL_IMPLEMENT_EXCEPTION_HANDLING and
#ifdef PL_IMPLEMENT_EXCEPTION_HANDLING

On 2017-07-22 22:47+0100 Phil Rosenberg wrote:

> [in that same e-mail] 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.

I initially didn't understand this explanation, but after _much_ too
long a time considering various scenarios to explain my point of view
the light finally dawned. Exception handling does not allow you to
transfer control to arbitrary places in the code (a stupid assumption
I was making). Instead, it merely allows you to unwind the call graph
from the plexit call (in this case that is the only current use of
PLTHROW in our source code) to return control to a routine potentially
far up the call stack from there such as _any_ of the public API
routines (as you said) that have a possible call to plexit somewhere
lower down on their call graph.

So sorry for my previous noise on this sub-topic, but
now we are finally on the same page in this regard, I have some
further questions and comments about your implementation of
exception handling and how you are using that exception handling
to deal with bad errors.

* If you miss putting a PLTRY and PLCATCH block in one of those public
   API cases where a potential call to plexit is somewhere lower on the
   call graph, then what does the current code do?  Does it simply
   crash (i.e., is that the potential cause of the serious issues I
   have reported to you in my previous post) or do you handle that
   internal error case by, e.g., emitting an "internal error: unhandled
   exception" message followed by an exit?

* What happens when an external application calls a "first" public API
   which has another "second" public API lower down in its call graph
   and even further down on the call graph of that second API occurs a
   potential call to plexit? Then if plexit is called that will PLTHROW
   control to the catch block of that second API rather than the first.
   So for this particular call graph case for the first API this second
   API needs to PLTHROW control to that first PLCATCH block rather than
   simply returning.  And, of course, since that second API is
   sometimes called directly from external applications and libraries
   without anything higher in the call graph with a PLCATCH block, it
   cannot PLTHROW all the time without sometimes running
   into the internal error discussed above.  So how are you going to figure out
   when to PLTHROW in a public API PLCATCH block and when not to PLTHROW?
   Or is that case already automatically taken care of by your present code
   (e.g., by each PLTRY macro incrementing a library status flag
   so that the PLCATCH macro can check that flag to see if there
   is a PLCATCH block higher in the call graph that it should PLTHROW
   to)?

* Shouldn't your current plexit call plend (like the master branch
   version does) to shut down the library?  See further discussion
   below concerning this suggestion.

* I also suggest you should implement a PLplot library state variable
   (let's call it plplot_library_status) that is initialized to 0 (good
   status) when the library is initialized but set to 1 (bad status) by
   plexit. Then follow up by implementing a c_plstatus() public API
   that returns the value of library_status and which emits a message
   such as ("library had bad error so it had to be shut down.  To use
   it again you need to initialize the library by calling one of the
   plinit family of routines".) Then an external application could call
   c_plstatus to check on the status of the library after any call to
   our public API and act accordingly.

   Or it could be sloppy about that (i.e., our standard C examples
   might only call plstatus in one example to make sure it works). In
   which case after the library is shutdown (see above) by an internal
   call to plexit there would be a blizzard of further plabort (due to
   plsc->level being 0) and plexit messages after the first one because
   of that library shutdown.  But there would be no call to the dreaded
   exit routine so there is at least the chance that the external
   application will survive that sloppiness.  And if plexit does not
   call plend, I think the chances of an external application
   encountering a showstopper error are much worse.

> 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.
>

I am frankly out of gas, and this is already a pretty long e-mail
so I will leave it to you to decide on the above topics unless
someone else here wants to comment.

Anyhow, after I get some sleep, I am looking forward to your further
comments on (a) my error report for interation 3, and (b) what I have
had the energy to discuss above.

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
__________________________