On Thursday, September 24, 2009 at 14:15:27 (-0700) Alan W. Irwin writes: > On 2009-09-24 21:34+0100 Andrew Ross wrote: > > > plexit calls plend _after_ the exit handler is called, and so if the exit > > handler > > throws an exception plplot will not call plend to tidy up and free memory. > > Provided > > that you do this yourself in your handler then you _should_ be ok. > > > > Of course, we would need to check all code paths with plexit in to make > > sure they > > don't leave any locally allocated memory unfreed. I don't know whether > > this is the > > case. It has probably never been thoroughly tested since we only tend to > > run > > valgrind on the examples which are set up not to generate any errors. > > Sorry for entering late to this conversation. I may have missed some key > piece of information earlier in the thread, but let me ask a "dumb" > question, anyway. plexit ultimately calls exit, which AFAIK immediately > exits without returning control to the routine that called the plplot > library in the first place. So plexit should be reserved (and I think it > normally is) for truly catastrophic errors where no means exist to recover. > For that case where a castrophe is occurring anyway, why are we concerned > about memory management issues? Why does plexit even bother to call plend? > Shouldn't it just send a message about the castrophic error and exit?
Throwing in my 2 cents, the user-specified error & abort handler exist to give the calling application some flexibility in how to handle plplot errors. Since we don't know a-priori how serious those errors may be, it's basically up to the user/application to decide how to proceed. If you want to override the default plplot behavior, simply have the user-supplied handler never return control to plplot. One could throw up an error dialog describing the nature of the problem, at which the user could take appropriate action. As has been pointed out in this thread, simply exiting could result in loss of a substantial amount of state. That said, continuing happily along from that point may not be "a good idea". Who knows what memory has been leaked, what internal corruption may have occurred, etc. I generally assume that if the code is too confused to continue, a segfault may be looming right around the corner, and it's best to save your data & fix/avoid whatever issue (bad inputs, experimental feature, etc) caused the problem to begin with. Or, you may get away with lots of these sorts of events if they're innocuous enough. In which case you've got to ask yourself one question: "Do I feel lucky?" ;) -- Maurice LeBrun ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
