FULL PRODUCT VERSION :
Seen on many versions of JDK6 and JDK7 up to current JDK7u51 build

ADDITIONAL OS VERSION INFORMATION :
Issue occurs on any OS

EXTRA RELEVANT SYSTEM CONFIGURATION :
This is irrelevant to the issue.

A DESCRIPTION OF THE PROBLEM :
We're getting java.lang.InternalError from XMLDocumentFragmentScannerImpl.scanDocument() instead of some sensible exception when trying to parse XML that contains unclosed tags - this should be handled more gracefull, specifically the method declares that it will throw XNIException, which would be appropriate to use here too. Throwing an Error is not appropriate, as consuming code will not be prepared to handle that, so client code cannot appropriately handle the "invalid XML" scenario and fails outright. The workaround of course is to catch Throwable, but that is an ugly hack.

This issue does not arise with Apache Xerces, only with the Sun-provided fork included in the JRE. Note that the bug report interface doesn't seem to offer an appropriate JDK/JRE component to use for Xerces.

Code view (not most recent) e.g. at http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java#XMLDocumentFragmentScannerImpl.scanDocument%28boolean%29

It is entirely to be expected that invalid documents will occasionally be fed into a parser, this mustn't be allowed to make the client code fall over, Errors are for unexpected things that one isn't expected to handle.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Example of a malformatted document fragment triggering this behavior (XML headers omitted):
--snip--
    <!-- Custom content types defined by this extension -->
    <content-handlers>
<content-handler>
<name value="Document Package" />
<handle value="resource/x-jjc-docset">
<http-actions>
<create value="modules/create.jsp">
<remove value="modules/remove.jsp">
</http-actions>
<icons>
<!--toolbar value="/images/add_ch1.gif"-->
<!--listitem value="assignment_on.gif"-->
</icons>
</content-handler>
    </content-handlers>
--snip--

Note how the <handle>, <create> and <remove> tags are not terminated, i.e it should read <create .... />. Clearly the document fragment is invalid XML, but that shouldn't throw an InternalError, it should raise a proper declared exception.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
XNIException should be thrown, as that's the method's declared exception (other than IOException, which is not applicable here)
ACTUAL -
java.lang.InternalError: processing event: -1

ERROR MESSAGES/STACK TRACES THAT OCCUR :
processing event: -1 - java.lang.InternalError: processing event: -1
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
        at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:235)
        at blackboard.xml.NonValidatingDOMParser.parse(NonValidatingDOMParser.java:115)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
use apache Xerces instead