[poppler] memory still reachable when calling Page::display()

[Albert Astals Cid]

A Diumenge, 29 de març de 2009, Vincent Torri va escriure:
> Hey,
>
> With the following code:
>
>    output_dev = new SplashOutputDev(splashModeXBGR8, 4, gFalse, white);
>
> [snip]
>
>    page->page->display (output_dev,
>                         72.0 * hscale,
>                         72.0 * vscale,
>                         rotate,
>                         false, false, false,
>                         doc->pdfdoc->getCatalog ());
>    color_ptr = output_dev->getBitmap ()->getDataPtr ();
>
> [snip]
>
>    delete output_dev;
>
>
> valgrind reports those still reachable memories:
>
> ==25494== 3,376 bytes in 1 blocks are still reachable in loss record 50 of
> 55 ==25494==    at 0x4C232CB: malloc (vg_replace_malloc.c:207)
> ==25494==    by 0x5440CAA: _cmsCreateProfilePlaceholder (in
> /usr/lib/liblcms.so.1.0.16) ==25494==    by 0x545708D: cmsCreateRGBProfile
> (in /usr/lib/liblcms.so.1.0.16) ==25494==    by 0x5457408:
> cmsCreate_sRGBProfile (in /usr/lib/liblcms.so.1.0.16) ==25494==    by
> 0x511A306: GfxColorSpace::setupColorProfiles() (GfxState.cc:305) ==25494== 
>   by 0x50F9BFA: Gfx::Gfx(XRef*, OutputDev*, int, Dict*, Catalog*, double,
> double, PDFRectangle*, PDFRectangle*, int, int (*)(void*), void*)
> (Gfx.cc:507) ==25494==    by 0x514090F: Page::createGfx(OutputDev*, double,
> double, int, int, int, int, int, int, int, int, Catalog*, int (*)(void*),
> void*, int (*)(Annot*, void*), void*) (Page.cc:408) ==25494==    by
> 0x5141124: Page::displaySlice(OutputDev*, double, double, int, int, int,
> int, int, int, int, int, Catalog*, int (*)(void*), void*, int (*)(Annot*,
> void*), void*) (Page.cc:437) ==25494==    by 0x51412FC:
> Page::display(OutputDev*, double, double, int, int, int, int, Catalog*, int
> (*)(void*), void*, int (*)(Annot*, void*), void*) (Page.cc:371) ==25494==  
>  by 0x4E311D6: epdf_page_render (epdf_page.cpp:114)
>
>
> It seems that cmsCloseProfile() is not called on RGBProfile. I don't
> really know where to call it, though

This is a similar situation to previous mail, displayProfile created the first 
time it's needed and not deleted anymore, however this should be more easy to 
fix since we can provide frontends hooks for creation and deletion of the 
color profiles.

As far as i remember Hal V. Engel was working on a patch to improve the "color 
management" management.

Hal how is it going?

Albert

>
> regards
>
> Vincent Torri
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler