Comment 14 for bug 583249

I knew I wouldn't be able to resist....

I've added [libxslt issue 67](https://gitlab.gnome.org/GNOME/libxslt/-/issues/67), which is a C-only reproduction of [libxslt issue 14](https://gitlab.gnome.org/GNOME/libxslt/-/issues/14). I note in that report that this may be a docbug, in the sense that this _may_ be intended behaviour but insufficiently clearly highlighted (I think that would be unfortunate).

I was thinking a little more about the aspect of the [other report](https://bugs.launchpad.net/lxml/+bug/1972065) that the double-free error happened only when it was a _part_ of the tree that was being transformed, and I wanted to understand how libxslt does what it does.

I don't know how lxml implements this transformation on a subtree, but in the attached tarball I include one way of doing this, which manages to produce the

    do-transform-3(95501,0x11be40600) malloc: *** error for object 0xffffffffffffffff: pointer being freed was not allocated

error if `AVOID_ERROR` is 0, and completes without error if it's defined to be true. I don't know if that's useful. informative, or interesting to you.

I'm conscious that there are two potentially very separate issues being discussed here, and possibly conflated, namely the double-free which I noticed in bug #1972065, and the double-transformation which this current report is focused on. The puzzling thing (to me) is that the double-free problem only seems to happen with a stylesheet which includes <xsl:strip-space/>, and it's that that is the link to the double-transformation problem.