Created attachment 69279 [details]
I've located two memory leaks in the pdf backend.
In cairo-type1-subset.c, _cairo_type1_font_subset_fini doesn't free font->cleartext (set by cairo_type1_font_subset_decrypt_eexec_segment).
In cairo-cff-subset.c, _cairo_cff_font_create can exit without freeing font->font_name and/or font->data; _cairo_cff_font_load_opentype_cff is called to allocate font_name, then _cairo_cff_font_load_cff is called to allocate font->data, then _cairo_cff_font_load_cff's return status is checked and if it failed, it jumps to fail1. This can cause font_name to leak since the fail1 target only frees the font variable. In addition, _cairo_cff_font_load_cff can fail -after- allocating data, and then data won't be freed either.
I've attached a patch against the latest (5a6e1d) commit in the master repo and a test case with a pdf I found on the web that triggers it.
Created attachment 69280 [details]
The test case
Created attachment 69281 [details]
PDF to trigger the leak
Thanks for the patch and test case.
on May 26, 2016 at 00:36:21.
(provided by the Example extension).