You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SAXParseException generating Scorecard for SonarQube #117
I am running into SAXParseException while trying to generate scorecard using ./createScorecards.sh. find the logs below
Analyzing results from Benchmark_1.2-findsecbugs-v1.4.6-xxx.xml
Actual results file generated: ~/Benchmark/scorecard/Benchmark_v1.2_Scorecard_for_FBwFindSecBugs_v1.4.6.csv
Report written to: ~/Benchmark/scorecard/Benchmark_v1.2_Scorecard_for_FBwFindSecBugs_v1.4.6.html
Analyzing results from Benchmark_1.2-sonar-v8.4.2.xxxxx-xxx.xml
[Fatal Error] :1:11: The markup in the document following the root element must be well-formed.
Error processing results/Benchmark_1.2-sonar-v8.4.2.xxxxx-xxx.xml. Continuing.
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 11; The markup in the document following the root element must be well-formed.
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at org.owasp.benchmark.score.BenchmarkScore.getXMLDocument(BenchmarkScore.java:1471)
at org.owasp.benchmark.score.BenchmarkScore.readActualResults(BenchmarkScore.java:790)
at org.owasp.benchmark.score.BenchmarkScore.process(BenchmarkScore.java:428)
at org.owasp.benchmark.score.BenchmarkScore.main(BenchmarkScore.java:336)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
at java.base/java.lang.Thread.run(Thread.java:834)
The Sonar results file Benchmark_1.2-sonar-v8.4.2.xxxxx-xxx.xml was generated by ./createScorecards.sh with SonarQube (docker 8.4.2-community instance) running locally.
How do i fix this issue.
SinceBenchmark_1.2-sonar-v8.4.2.xxxxx-xxx.xml file is large ~18 MB i haven't attached it here. Let me know if it you like to get hold of it.
The SonarQube parser is very old so I'm not surprised it doesn't work anymore. I'd love to update it though. Can you share the results file with me? dave dot wichers at owasp dot org is my email. And I'll update the scorecard generator to support the current XML results format.
@akhvee This XML file does not have a root tag. Even adding one artificially does not fix the file. How did you get/export this one? 🤔 @davewichers the scorecard generator can parse both xml and json (while JSON is self created through scraping SonarQube's API). So this is still an issue for XML files.
@darkspirit510 - I've had tools generate invalid XML like this before. When this occurs, I've had to insert the required XML elements at the start/end of the file to 'fix' the XML, before sending it to the XML parser. This may need to be done if SonarQube is generating something that is actually invalid. Let's see what @akhvee says about how the XML was actually generated.
This can be closed at your convenience @darkspirit510@davewichers
This issue has been resolved through several improvements to BenchmarkUtils since 2020. Here's the breakdown:
What caused the original crash:
The 2020 code path went through BenchmarkScore.getXMLDocument() which tried to parse every results file as standard XML before any tool-specific reader could handle it. SonarQube's XML
export has multiple root elements (e.g., ......), which violates the XML spec requiring a single root element. The generic parser hit this and
threw SAXParseException immediately.
What's been fixed (3 layers):
ResultFile class (added 2022 by @darkspirit510) — The old getXMLDocument() code path no longer exists. XML parsing now happens in ResultFile.parseXml(), where parse failures are
caught gracefully. A malformed XML file simply results in isXml() returning false — no crash, no stack trace.
SonarQubeReader.parse() — The XML-based reader already handles the multi-root-element problem by wrapping the raw content in a synthetic root element before parsing:
String fixed = "" + resultFile.content() + "";
This directly addresses the SAXParseException from the original report.
SonarQubeJsonReader + SonarReport.java — For modern SonarQube versions, a JSON-based workflow was added. SonarReport.java scrapes the SonarQube API and produces a well-formed JSON
results file, and SonarQubeJsonReader parses it. This bypasses XML entirely and is the recommended path for current SonarQube versions.
Additionally, BenchmarkScore.process() now wraps each tool's result processing in a try-catch that logs the error and continues to the next file, so even an unrecognized format won't
halt the entire scorecard generation.
Conclusion: The stack trace from this issue cannot occur with the current codebase. The generic XML parsing bottleneck was eliminated, the SonarQube XML reader handles malformed input,
and the preferred path for modern SonarQube is JSON. Safe to close.
Activity
[-]Exception generating Scorecards[/-][+]SAXParseException generating Scorecards[/+]davewichers commentedon Sep 17, 2020
The SonarQube parser is very old so I'm not surprised it doesn't work anymore. I'd love to update it though. Can you share the results file with me? dave dot wichers at owasp dot org is my email. And I'll update the scorecard generator to support the current XML results format.
akhvee commentedon Sep 17, 2020
Results file attached
Benchmark_1.2-sonar-v8.4.2-x.xml.zip
[-]SAXParseException generating Scorecards[/-][+]SAXParseException generating Scorecard for SonarQube[/+]davewichers commentedon Oct 7, 2021
@darkspirit510 - Sascha - is this still an issue anymore for the updated version of SonarQube scorecard generator?
darkspirit510 commentedon Oct 18, 2021
@akhvee This XML file does not have a root tag. Even adding one artificially does not fix the file. How did you get/export this one? 🤔
@davewichers the scorecard generator can parse both xml and json (while JSON is self created through scraping SonarQube's API). So this is still an issue for XML files.
davewichers commentedon Oct 18, 2021
@darkspirit510 - I've had tools generate invalid XML like this before. When this occurs, I've had to insert the required XML elements at the start/end of the file to 'fix' the XML, before sending it to the XML parser. This may need to be done if SonarQube is generating something that is actually invalid. Let's see what @akhvee says about how the XML was actually generated.
TheAuditorTool commentedon Apr 13, 2026
This can be closed at your convenience @darkspirit510 @davewichers
This issue has been resolved through several improvements to BenchmarkUtils since 2020. Here's the breakdown:
What caused the original crash:
The 2020 code path went through BenchmarkScore.getXMLDocument() which tried to parse every results file as standard XML before any tool-specific reader could handle it. SonarQube's XML
export has multiple root elements (e.g., ......), which violates the XML spec requiring a single root element. The generic parser hit this and
threw SAXParseException immediately.
What's been fixed (3 layers):
caught gracefully. A malformed XML file simply results in isXml() returning false — no crash, no stack trace.
String fixed = "" + resultFile.content() + "";
results file, and SonarQubeJsonReader parses it. This bypasses XML entirely and is the recommended path for current SonarQube versions.
Additionally, BenchmarkScore.process() now wraps each tool's result processing in a try-catch that logs the error and continues to the next file, so even an unrecognized format won't
halt the entire scorecard generation.
Conclusion: The stack trace from this issue cannot occur with the current codebase. The generic XML parsing bottleneck was eliminated, the SonarQube XML reader handles malformed input,
and the preferred path for modern SonarQube is JSON. Safe to close.
davewichers commentedon Apr 13, 2026
@darkspirit510 - If you agree, I'll close this.