Re: [xml] Regarding Malloc Failure Handling

On Mon, Mar 24, 2008 at 02:55:05PM +0530, Ashwin wrote:
Ashwin wrote:

Recently we performed failure testing on libxml, that is we simulated

failures to see how libxml behaved in that scenario. As a result of the

testing we found a number of memory leaks and some crashes.

          There are other similar problems, so I was wondering if there

an assumption that malloc failure will not occur since it is a rare

occurrence. Or does corrective action need to be taken wherever it occurs

the failure path. 


In almost all of the code, malloc failures are handled correctly as
errors, so

if you find places where that's not the case, that should be considered a



Actually the problem is a little more complex, there are situations where
xmlParseDocument will return success but the tree which has been generated
will be broken,(which is due to a malloc failure somewhere, however in the
failure return path in some cases there is no indication to trigger a
parsing failure), for example it will have an element node, but the element
name will be NULL, and in any case the tree returned will not be complete.
This happens generally in cases where we have a malloc failure for StrDup &
StrnDup, one solution might be to set the wellFormed flag  to 0 in ErrMemory
functions, however that too will not work because the ctxt is not available
everywhere these functions are invoked & strndup explicitly passes the ctxt
as NULL. So controlling that kind of behaviour might be a little difficult,
that is what led me to believe that perhaps malloc failure was not
considered, or more appropriately wasn't considered for the entire flow. 

  Yes memory allocation failures should be handled, at least be reported,
and of course not leaking or crashing. However it's really hard to perfectly
handle out of memory failures.
  One thing though is that one-time memory failures failing to allocate say 
a string or a node are rather unlikely, usually, if you hit a memory failure
most future allocations will fail at least for some user perceivable time
which means a very long time from a code equence point of view.
  We really need to fix leaks or crashes and report the error though the
API, anything beyond that is nice but less critical. If the application chose
to ignore the memory error, nothing can be done to save it anyway.


Red Hat Virtualization group
Daniel Veillard      | virtualization library
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]