GNOME Bugzilla – Bug 626779
xmllint infinite loop parsing RNG file
Last modified: 2021-07-05 13:27:26 UTC
There is an RNG file at http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng which causes xmllint to go into an infinite loop when specified as schema. This file is widely used in the TEI community, since it defines TEI/XML at it's most generic. It is a notorious memory hog. For example the command line: xmllint --relaxng tei_all.rng - never blocks to read from stdin whereas the commandl ine xmllint --relaxng tei_all.rng --huge --stream - reads an xml file from stdin but never completes, even for trivial XML files. In both cases monitoring reports a single CPU at 100% indefinitely. I'm on 32bit ubuntu running: xmllint: using libxml version 20705 compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib There have been reports that this works, however, for older versions and MacOS versions. See discussion at http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1008&L=tei-l&T=0&F=&S=&P=2878
Hi, I followed the discussion on TEI-L too, here is the entry point: http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1008&L=tei-l&D=0&T=0&P=2551 In contrast to Stuarts posting, my version: xmllint: using libxml version 20632 compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib on a 64bit Xubuntu has the problem too. So ... may be the bits are a hint. Cheers, TAq.
Hi again, the infinite loop can be found in relaxng.c lines 4206-4209: /** * xmlRelaxNGCheckGroupAttrs: * @ctxt: a Relax-NG parser context * @def: the group definition * * Detects violations of rule 7.3 */ static void xmlRelaxNGCheckGroupAttrs(xmlRelaxNGParserCtxtPtr ctxt, xmlRelaxNGDefinePtr def) { [...] /* * Don't run that check in case of error. Infinite recursion * becomes possible. */ if (ctxt->nbErrors != 0) return; cur = def->attrs; ! while (cur != NULL) { ! nbchild++; ! cur = cur->next; ! } [...] } The comment matches the situation, but the solution seems to be incomplete. Cheers, TAq.
The comment doesn't quite match the situation, surely, since we have infinite looping rather than infinite recursion. At least I'm assuming that it was infinite looping rather than infinite recursion, since after ~30 minutes it hadn't run out of memory as would be the expected result of infinite recursion.
(In reply to comment #3) > The comment doesn't quite match the situation, surely, since we have infinite > looping rather than infinite recursion. At least I'm assuming that it was > infinite looping rather than infinite recursion, since after ~30 minutes it > hadn't run out of memory as would be the expected result of infinite recursion. Yes, you are right. :) We are talking about an infinite loop (lines marked by '!'). The comment was right there when I found the given code section. I mentioned it because there once was a similar problem with a solution that may be applicable to our current in some way. Regards, TAq.
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.