| Summary: | Memory leaks in font-related code | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Kevin Tardif <kiyoka> |
| Component: | pdf backend | Assignee: | Adrian Johnson <ajohnson> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | major | ||
| Priority: | medium | ||
| Version: | 1.12.6 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
The patch
The test case PDF to trigger the leak |
||
Created attachment 69280 [details]
The test case
Created attachment 69281 [details]
PDF to trigger the leak
Thanks for the patch and test case. http://cgit.freedesktop.org/cairo/commit/?id=65176b7380f0d633da514be1febe16f17b99d876 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 69279 [details] The patch 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.