When an XPath error occurs when calling the /api/xml API, the entire xml string writer object is included as part of the exception. While this could be useful in some circumstances, it poses a problem when there is a significant amount of xml (i.e. tens or hundreds of megabytes).

Recently I saw this in my jenkins installation. One of the chrome extensions calls "/api/xml?depth=2&xpath=/*/job/lastBuild&wrapper=hudson" to get information every minute or two. I was seeing 150MB of log data every time that call was made because there was a stack trace followed by:

Caused by: hudson.util.IOException2: Failed to do XPath/wrapper handling. XML is as follows:<hudson><assignedLabel><busyExecutors>0</busyExecutors><description>... [150MB of xml]</hudson>
at hudson.model.Api.doXml(Api.java:142)
... 63 more
Caused by: org.dom4j.DocumentException: Error on line 2170 of document : An invalid XML character (Unicode: 0x10) was found in the element content of the document. Nested exception: An invalid XML character (Unicode: 0x10) was found in the element content of the document.
at org.dom4j.io.SAXReader.read(SAXReader.java:482)
at org.dom4j.io.SAXReader.read(SAXReader.java:365)
at hudson.model.Api.doXml(Api.java:100)
... 63 more
Caused by: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x10) was found in the element content of the document.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2894)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
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.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at org.dom4j.io.SAXReader.read(SAXReader.java:465)
... 65 more

It didn't take very long for the log file to consume all of the available disk space on the server and thereby halt the jenkins service.

Clearly there is something wrong with the XML document or XPath requests, but the log file shouldn't cripple my system as a result.

I marked this as Major because it can halt the jenkins service.