[
https://issues.apache.org/jira/browse/XERCESC-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1781:
-------------------------------------
Fix Version/s: 2.9.0
3.0.0
> Removing the content handler from SAX2XMLReader mid-parse causes a
> null-pointer exception in some circumstances
> ---------------------------------------------------------------------------------------------------------------
>
> Key: XERCESC-1781
> URL: https://issues.apache.org/jira/browse/XERCESC-1781
> Project: Xerces-C++
> Issue Type: Bug
> Components: SAX/SAX2
> Affects Versions: 2.8.0
> Reporter: Alex Smith
> Priority: Minor
> Fix For: 3.0.0, 2.9.0
>
> Attachments: xerces-c-handler-checking.patch
>
>
> The documentation for SAX2XMLReader states that one may change the handlers
> (e.g. content handler) during a parse (i.e. from a handler callback) and the
> new handler will be used immediately. This is true but in some circumstances
> it is possible cause a null-pointer exception by removing a handler from
> within a callback.
> For example consider an application which has installed an advanced document
> handler but also wants access to the Locator object so initially sets a
> regular content handler (this is how I came across this issue). The content
> handler need only implement the setDocumentLocator method and once this
> method has been called and the pointer to the locator saved it can be
> removed. Indeed it is desirable to remove it once its work is done to reduce
> overhead.
> However a call to setContentHandler(NULL) of the SAX2XMLReader from within
> the setDocumentLocator handler method causes a null-pointer exception. This
> is because the startDocument handler method is called immediately afterwards
> without checking that the handler pointer is still valid. Of course the
> work-around is trivial; move the setContentHandler(NULL) call to the
> startDocument handler.
> There are various other handler methods where similar problems could occur.
> For example endElement is called after startElement in the case of an empty
> element and again it is assumed that the handler pointer remains valid. The
> situation here might be an application which needs to examine only the root
> element (e.g. to obtain information about the namespace) but wishes to parse
> the whole document to obtain any error information (so only the content
> handler is removed in startElement, not the error handler). This would work
> fine for most documents and the flaw would likely not be noticed but a
> document with an empty root element would crash the application (potential a
> security issue).
> The LexicalHandler also has one instance where this problem could arise.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
