corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Checking malloc success and adding perror()
Date Thu, 19 Feb 2015 19:26:47 GMT
Continuing, sort of, beyond the comment on small points,

4. NOT A SMALL POINT.  Peter's observation about private allocators and reference counting
reminds me that we could also be using the Microsoft COM binary interface, with its scheme
for reference counting), but using our own interface factories.  This is also a good way to
pass an interface to quick-check code so that the caller can provide an error handler, except
for the fact that COM interfaces are not allowed to produce exceptions.  This doesn't get
the stack walkback that I think Peter is talking about.  That takes a different kind of magic.
 It does handle the correct release of shared in-memory data structures.

There are fully-portable definitions of COM interfaces that work on any C/C++ compiler model
(that allow pointers to functions in structs), although it is nicer when the code is compiled
as C++ even though the bindings are all for C.  It is not necessary to go the IDL and MIDL
compiler route for strictly in-process local usages in native code, and there is no need for
the COM system manager or any other run-time additions.

 5. (4) is not a small point.  I just wanted to point out that there is a well-defined
reference-counting interface scheme that is widely used, although often under the cover of
C++ class definitions.  This is very interesting, though, for dynamic integration of different
filters and for filters to be able to communicate with their hosts as is demonstrated with
the Java JNI technique (one that I have applied in practice).  

I have not done the work to see how well something like that slides under the AOO UNO scheme,
but it appears to have the same reference-count handling but with different method names.
 This would be a much longer, but perhaps extremely profitable line of investigation.  

I am committed to exploring this avenue whether on behalf of Corinthia or Apache OpenOffice
or none of the above.  My work on building document-processing tools from the Zip (i.e., the
ISO DCF format, OPC, ODF Package) on up will follow this course.

 - Dennis

PS: To the horror of some, it is discovered that COM is back as a fundamental kind of dynamic
glue in the Windows runtime.  (I say some ideas are just too good to stay dead.)  Although
it figures in conjunction with what was called the WinRT API, it is pretty invisible in .NET
languages, where COM use is near invisible.  What interests me is how this works into the
asynchronous coordination model of WinRT and therefore Windows Universal apps.  I have no
idea at this point.

-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org] 
Sent: Thursday, February 19, 2015 04:51
To: dev@corinthia.incubator.apache.org
Subject: Re: Checking malloc success and adding perror()

> On 19 Feb 2015, at 6:15 pm, jan i <jani@apache.org> wrote:
> 
> On 19 February 2015 at 05:05, Peter Kelly <pmkelly@apache.org> wrote:
> 
>> The next thing to address i cleanup. If a malloc failure occurs deep in a
>> conversion run, and we jump out to an exception handler, we should free all
>> memory that was allocated during that run. This means wrapping
>> malloc/calloc/realloc/strdup and any other functions in the C library, and
>> using our own data structure to keep track of what has been allocated (and
>> also to update this data structure when memory is freed). Then, if an error
>> occurs, after we return to the call site of setjmp() and go into the
>> exception handling block, we go through this data structure and call free()
>> on all the blocks of memory that were allocated by DocFormats, so the
>> application can then show an error message and then continue operating.
>> 
> Now this is quite a different discussion.....do we want to recover
> gracefully from severe errors or simply make sure the whole application
> terminates.
> 
> I advocate that we cannot recover gracefully from all severe errors, so no
> reason breaking our backs trying.

I think it’s worth a try. The exception handling approach along the lines of what I mentioned
I did with TeX would work. If we ensure all allocations go through our wrapper functions,
then we can ensure that memory is freed when we do have a problem, and then return an appropriate
error code to the application.

Of course that doesn’t address logic errors in the code, which can still cause crashes,
but would nicely handle the case of out-of-memory problems.

The wrapper functions will also make testing of this much easier; we can have a test driver
option that causes allocation to fail after a randomly-chosen number of calls, and repeat
a conversion with the same input many times but different failure injection points.

—
Dr Peter M. Kelly
pmkelly@apache.org

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)



Mime
View raw message