On Wed, Aug 31, 2022 at 08:36:01AM +0900, Michael Paquier wrote:
> There have been more failures, always switching the input from
> "pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post"
> to "pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&deep</n2>post".
>
> Using a PATH of node() influences the output. I am not verse unto
> XMLTABLE, but could it be an issue where each node is parsed and we
> have something like a qsort() applied on the pointer addresses for
> each part or something like that, causing the output to become
> unstable?
Hmm. I think that I may have an idea here after looking at our xml.c
and xpath.c in libxml2/. From what I understand, we process the PATH
through XmlTableGetValue() that builds a XML node path in
xmlXPathCompiledEval(). The interesting part comes from libxml2's
xmlXPathCompiledEvalInternal(), where I think we don't apply a sort on
the contents generated. Hence, I am wondering if the solution here
would be to do one xmlXPathNodeSetSort(xpathobj->nodesetval) after
compiling the path with xmlXPathCompiledEval() in XmlTableGetValue().
This should ensure that the items are ordered even if ASLR mixes if
the pointer positions.
A complete solution would involve more code paths, but we'd need only
one change in XmlTableGetValue() for the current regression tests to
work. I don't have an environment where I can reproduce that, so that
would be up to the buildfarm to stress this solution..
Thoughts?
--
Michael
