[xml/sgml-pkgs] Bug#287371: xsltproc: Probable memory leak (when using document()?)

[Diederik de Haas]

Control: tag -1 unreproducible

On Wed, 9 Feb 2005 17:12:21 +0100 Mike Hommey <mh at glandium.org> wrote:
> On Dec 27, 2004, Vincent Lefevre <vincent at 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 <vincent at 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 <mattia at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: website.dtd
Type: application/xml-dtd
Size: 2617 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-xml-sgml-pkgs/attachments/20230217/7499585d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/debian-xml-sgml-pkgs/attachments/20230217/7499585d/attachment.sig>