GNOME Bugzilla – Bug 346586
xsltproc return error code 0 even if errors occur
Last modified: 2021-07-05 13:26:35 UTC
Please describe the problem: In some special cases of xslt crafting, there are namespace error, but the xsltproc return 0. Thinks like configure script then guess xsltproc is supporting a specific crafting while in fact it is not fully supporting it. It should return a non 0 value as soon as it provide an 'error' message on console! Steps to reproduce: 1. use the provided .xsl and .xml files (.xsl is the important part) 2. /usr/bin/xsltproc -o configtest.out configtest.xsl configtest.xml 3. result: tchize@Yuki:~/dev/crossfire$ /usr/bin/xsltproc -o configtest.out configtest.xsl configtest.xml namespace error : Namespace prefix xsl on text is not defined <xsl:text> </xsl:text> ^ tchize@Yuki:~/dev/crossfire$ echo $? 0 Actual results: return value 0: normal Expected results: Should return value 5: error in the stylesheet Does this happen every time? Yes Other information: See attached .xsl files
Created attachment 68363 [details] the xsl file The crafted xsl file
Created attachment 68364 [details] The xml that goes along with test
Note: I know that <!DOCTYPE xsl:stylesheet [ <!ENTITY tab "<xsl:text> </xsl:text>"> <!-- Tab --> ]> is not a perfect thing to do in a .xsl, the problem is not (currently) that xsltproc issue and error with it, the problem is that behaviour is inconsistent with return value, confusing automated scripts.
What you see is a namespace error emitted by libxml2, not a transformation error emitted by libxslt or xsltproc. It is not a fatal error, the document get parsed anyway. As a result the transformation is being done, and process successfully. Since the goal of xsltproc is to do transformation, and that transformation is completed, return value is 0. From my point of view the current behaviour is normal. Daniel
Created attachment 68385 [details] more explicit stylesheet This is a more explicit stylesheet to prove there is really a problem as the result of xsl parsing is not the one expected
Created attachment 68386 [details] Result of xsltproc Result of running the more explicit stylesheet with xsltproc
Created attachment 68387 [details] Expected result This is the to be excpected result
There is really a problem! As a result of this parsing error, xsltproc is ignoring the entities defined in the DOCTYPE header. The resulting file is then not the one expected. This is not a fatal error parsing the stylesheet, as you said, but it is an error anyway. The documentation of xsltproc states: xsltproc's return codes provide information that can be used when calling it from scripts. ... "5 Error in the stylesheet" Fatal errors would obviously go to "4 Failed to parse the stylesheet", while non fatal errors in stylesheet (like this one) should go to 5. I don't see in this documentation where this return code (5) is limited to fatal errors. Moreover, the return code 0 is limited to "No error (normal operation)", and we clearly are in a case where it is not a "no error". The console states there is an error, the xslt process is ignoring entities, and the resulting document is wrong.
Not fixeable without some non-trivial work in the parser core. I could explain why and how, but a bugzilla entry is not the best place to carry this, get on the mailing list (see xmlsoft.org/bugs.html) and ask there. Daniel
Dunno if this is a simmilar case. I recently switched from entities to xi:include and noticed that xsltproc was failing for missing enternal entities, but it does not fail for missing xi:includes (that have no fallback). Is this fixable (should I create a new bug?)?
XInclude processing is really an add-on in the XML tool chain. But where errors can be caught we should try. One thing you can try when scripting is instead of processing XInclude from xsltproc, use xmllint first to generate the XIncluded document, the use that for xsltproc. Maybe you will get finer results as I think xmllint will report such problems: if (xmlXIncludeProcessFlags(doc, options) < 0) progresult = XMLLINT_ERR_UNCLASS; Daniel
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libxml2/-/issues/ Thank you for your understanding and your help.