On 07.03.2011 05:25, Daniel Veillard wrote:
> I believe any libxslt compiled without XSLT_REFACTORED leacked this for
> xsl:number.
Yes, apparently so.
But with XSLT_REFACTORED defined, compilation fails in preproc.c around
line 423. This makes me wonder if XSLT_REFACTORED is the recommended
setting? Is it any faster / more stable / better tested?
I am not sure if the following change is correct, but at least it
compiles fine and correctly frees all memory which leaked previously:
case XSLT_FUNC_NUMBER: {
xsltStyleItemNumberPtr item = (xsltStyleItemSortPtr)
comp;
if (item->numdata.countPat != NULL)
xsltFreeCompMatchList(item->numdata.countPat);
if (item->numdata.fromPat != NULL)
xsltFreeCompMatchList(item->numdata.fromPat);
}
> I also reran "make valgrind" and it seems fine now...
Fine here too, no more leaks with the latest changes.
> BTW your libxnlt is compiled with memory debug in the logs, not sure
> you want that setup all the time :-)
I know. Memory debug is required to show the memory leak trace. It is
turned off for production. Anyway, thanks for pointing it out!
Ralf
_______________________________________________
xslt mailing list, project page http://xmlsoft.org/XSLT/
[email protected]
http://mail.gnome.org/mailman/listinfo/xslt