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 > 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.
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. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
