Control: tag -1 unreproducible On Wed, 9 Feb 2005 17:12:21 +0100 Mike Hommey <m...@glandium.org> wrote: > On Dec 27, 2004, Vincent Lefevre <vinc...@vinc17.org> wrote: > > Package: xsltproc > > Version: 1.1.8-5 > > > > Here xsltproc takes up to 138 MB, making the whole system slow down > > due to swapping. This problem occurs when generating my blog page, > > where a document() is used for each blog item (this will change in > > the future, but the current behavior shouldn't occur). The sources > > are in a DocBook-based DTD that can be downloaded from > > > > http://www.vinc17.org/DTD/website.dtd > > > > I'm not including the XML sources since this is quite complicated > > (lots of inclusions and dependencies). But if the bug is not known, > > I could try to build a simpler example. > > How big is the document you load with document() ? How many times it > gets loaded ? Could you provide me the files ?
The year is 2023, which means that 18 YEARS ago you were asked to provide a sample document ... which still hasn't happened. It was reported again xslt version 1.1.8-5 with some mention of version 2.6.16-1 of libxml2 ... both are ANCIENT, but no newer 'found' version was reported. Just for fun, I downloaded your dtd (attached) and noticed a MathML entity which refers to DTD: "http://www.w3.org/TR/MathML2/dtd/mathml2.dtd Trying to load that document gives a 404, but I found the following: https://www.w3.org/TR/MathML2/appendixa.html#parsing.usingdtdt My XML knowledge is a bit rusty, but that means your *custom made* DTD is invalid? On Sat, 19 Feb 2022 18:28:00 +0100 Vincent Lefevre <vinc...@vinc17.net> wrote: > I'll test again (I've been using a fake DTD for the past 15 years). IOW: you're not using your own DTD ... otherwise you might have noticed it's no longer valid? What I do recall from when I was full into XML and related technologies is that it indeed uses a lot of memory. As mentioned in 2005, 138MB is not considered *that* much. And in 2023 that is even more true. But you have a machine with *unspecified* but apparently very limited resources and there you try to load a *custom made* DTD which is probably quite complex (MathML can't be simple AFAIK). "What could possibly go wrong (tm)" On Sat, 19 Feb 2022 18:01:52 +0100 Mattia Rizzolo <mat...@debian.org> wrote: > If you believe so, and you confirmed that it hasn't been fixed in the > past 15 years, could you please either (or both): > * report it to mitre's CVE form > * report it in https://gitlab.gnome.org/GNOME/libxml2/-/issues > ? That request was made a YEAR ago, but I'm not seeing a 'forwarded'? Or a link to a CVE item? And the final message in this bug is that you run Out Of Memory, so the OOM killer does exactly what it needs to do: kill other programs. But yet, you conclude that this is all xsltproc's fault? There was no action on this bug for ~ 17 years, any requested information was not provided, the issue was not made reproducible, it was not reported upstream and I'm probably 'forgetting' a few items. How in the world could this possibly be considered Release Critical? I'll leave changing the severity to the maintainer, but 'wishlist' seems appropriate to me.
website.dtd
Description: application/xml-dtd
signature.asc
Description: This is a digitally signed message part.
