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
signature.asc
Description: PGP signature