[jira] Resolved: (XERCESC-1781) Removing the content handler from SAX2XMLReader mid-parse causes a null-pointer exception in some circumstances

["Alberto Massari (JIRA)" <xe...@xml.apache.org>]

     [ https://issues.apache.org/jira/browse/XERCESC-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alberto Massari resolved XERCESC-1781.
--------------------------------------

    Resolution: Fixed
      Assignee: Alberto Massari

Fix is in SVN

> 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
>            Assignee: Alberto Massari
>            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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org