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

Reply via email to