SonarXML bug when parsing multiline comments in DOCTYPE definition


Since I’ve upgraded my SonarQube instance to version 6.x LTS and updated my SonarXML plugin I get an exception when the XmlSensor tries to highlight some XML code. I’ve neved had problems with those XML files before the upgrade.

Versions used and project config:

  • SonarQube: 6.7.5
  • SonarXML:
  • SonarQube Maven Plugin:
  • pom source-enconding: iso-8859-1
  • source file enconding: iso-8859-1

Error observed:

  • This simple XML file produces an exception when analizing (I’ve simplified the original one just to focus on the problem):
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE menu [
Some comment
<!ELEMENT menu (modulo)* >
  • This is the exception I get:
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin: (default-cli) on project foo: Unable to analyse file C:/tmp/foo/include/foo.xml: Unable to highlight file include/foo.xml: 5 is not a valid line offset for pointer. File include/foo.xml has 2 character(s) at line 7 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin: (default-cli) on project foo: Unable to analyse file C:/tmp/foo/include/foo.xml

Steps to reproduce

  • Analize the provided xml with a SonarQube Maven Scanner

Potential workaround

  • Based on several tests I’ve performed, my guess is that the exception raises when the XML file has a multiline comment and the starting delimiter is followed by a new line, with no whitespace between.
  • If you write a whitespace between the starting delimiter and the newline "<!-- " you’ll be able to avoid the exception.

Can you confirm this bug?

1 Like

I have another XML file that raises a similar exception.

<!DOCTYPE glassfish-web-app PUBLIC "-//
GlassFish Application Server 3.1 Servlet 3.0//EN"
    <parameter-encoding default-charset="UTF-8" />

In this case, there’s no multiline comment in the XML file itself but the referenced DTD has some multiline comments in its definition.

Hey @jmcubel ,

Thanks a lot for your very precise reproducer and early analysis. It’s quite a nice bug. It is indeed related to how the XML analyzer is handling the (lack of) spaces in comments when parsing.

I consequently created the following JIRA ticket to handle it: SONARXML-73

I have not been able to reproduce the issue with your second example. However I’m quite sure it does not come from the DTD, as we are not trying to read it, and the analyzer is also not checking the XML file consistency. Maybe it’s also a question of trailing space somewhere, but so far I have not been able to make my analysis of it fail on this one.


1 Like

Hello @Michael.

I’ve seen all SonarXML 2.0 issues are already solved.

Do you know when this version will be released?



Hey @jmcubel,

SonarXML 2.0.1 have been released on January, 14th (I forgot to click ‘release’ on JIRA). It should be already available through the SonarQube Marketplace. Note that It has already been already deployed on SonarCloud 2 weeks ago.

You may want to have look at the product announcement: