It appears that the switch from KXml2Driver to StandardStaxDriver in JENKINS-69129 (included in 2.387.3-rc33338.349f385d65d2 as well as weeklies) broke the ability to round-trip ASCII NUL characters in text. Prior to the change, this character was written as � and (whether correct or not) read back successfully. After the change, it is still written the same way, but cannot be read.
Seems unlikely to affect many users, though it may affect the Jenkins project itself: for example
mvn -pl test surefire:test -Dtest=ExecutorTest#disconnectCause_WithoutTrace -Dmaven.test.redirectTestOutputToFile=true
causes TEST-hudson.model.ExecutorTest.xml to include
<===[JENKINS REMOTING CAPACITY]===>���channel started
which looks to be bogus output from Surefire but which does not trigger a problem, whereas hudson.model.ExecutorTest-output.txt contains
<===[JENKINS REMOTING CAPACITY]===>^@^@^@channel started
(with ^@ standing in for actual ASCII NUL for display). In case the NUL makes it into a stdout field in junitResult.xml, the symptom is that the junit step publishes test results normally (setting the build status, sending checks to GitHub, etc.) but if you visit the testReport/ display in the GUI, it claims there are no tests found (after printing a stack trace to the system log about a parse error). Other plugins looking up test results (such as parallel-test-executor) can also be affected.
Originally reported by 
jglick, imported from: XStream2 unable to round-trip ASCII NUL in stdout/stderr in junitResult.xml
- assignee: jglick
- status: Closed
- priority: Critical
- component(s): core
- label(s): 2.387.3-rejected, 2.401.1-fixed, regression, xml, xstream
- resolution: Fixed
- resolved: 2023-04-26T12:20:17+00:00
- votes: 0
- watchers: 5
- imported: 2025-11-24
Raw content of original issue
It appears that the switch from KXml2Driver to StandardStaxDriver in JENKINS-69129 (included in 2.387.3-rc33338.349f385d65d2 as well as weeklies) broke the ability to round-trip ASCII NUL characters in text. Prior to the change, this character was written as � and (whether correct or not) read back successfully. After the change, it is still written the same way, but cannot be read.
Seems unlikely to affect many users, though it may affect the Jenkins project itself: for example
mvn -pl test surefire:test -Dtest=ExecutorTest#disconnectCause_WithoutTrace -Dmaven.test.redirectTestOutputToFile=true
causes TEST-hudson.model.ExecutorTest.xml to include
<===[JENKINS REMOTING CAPACITY]===>&#0;&#0;&#0;channel started
which looks to be bogus output from Surefire but which does not trigger a problem, whereas hudson.model.ExecutorTest-output.txt contains
<===[JENKINS REMOTING CAPACITY]===>^@^@^@channel started
(with ^@ standing in for actual ASCII NUL for display). In case the NUL makes it into a stdout field in junitResult.xml, the symptom is that the junit step publishes test results normally (setting the build status, sending checks to GitHub, etc.) but if you visit the testReport/ display in the GUI, it claims there are no tests found (after printing a stack trace to the system log about a parse error). Other plugins looking up test results (such as parallel-test-executor) can also be affected.
It appears that the switch from KXml2Driver to StandardStaxDriver in
JENKINS-69129(included in 2.387.3-rc33338.349f385d65d2 as well as weeklies) broke the ability to round-trip ASCII NUL characters in text. Prior to the change, this character was written as � and (whether correct or not) read back successfully. After the change, it is still written the same way, but cannot be read.Seems unlikely to affect many users, though it may affect the Jenkins project itself: for example
mvn -pl test surefire:test -Dtest=ExecutorTest#disconnectCause_WithoutTrace -Dmaven.test.redirectTestOutputToFile=truecauses TEST-hudson.model.ExecutorTest.xml to include
<===[JENKINS REMOTING CAPACITY]===>���channel startedwhich looks to be bogus output from Surefire but which does not trigger a problem, whereas hudson.model.ExecutorTest-output.txt contains
(with ^@ standing in for actual ASCII NUL for display). In case the NUL makes it into a stdout field in junitResult.xml, the symptom is that the junit step publishes test results normally (setting the build status, sending checks to GitHub, etc.) but if you visit the testReport/ display in the GUI, it claims there are no tests found (after printing a stack trace to the system log about a parse error). Other plugins looking up test results (such as parallel-test-executor) can also be affected.
Originally reported by
jglick, imported from: XStream2 unable to round-trip ASCII NUL in stdout/stderr in junitResult.xml
Raw content of original issue