|
Ashwin wrote: >> Recently we performed failure testing on libxml, that is we simulated malloc >> 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 is >> 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 in >> 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 bug > IMHO.
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.
Regards Ashwin |