R devel - Jan 2023 - memory leak in png()

Hi all,

Yesterday I discovered what seems to me like a memory leak in png() so I'm
reporting it in case that is helpful. Here is a small reproducible example:

R -d "valgrind --tool=memcheck --track-origins=yes --leak-check=full"
--vanilla -e "png(filename='p.png'); plot(1:10); dev.off()"
## HAS LEAK
==1021711== LEAK SUMMARY:
==1021711==    definitely lost: 9,216 bytes in 30 blocks
==1021711==    indirectly lost: 19,370 bytes in 838 blocks
==1021711==      possibly lost: 3,868 bytes in 8 blocks

R -d "valgrind --tool=memcheck --track-origins=yes --leak-check=full"
--vanilla -e "pdf(file='p.pdf'); plot(1:10); dev.off()"
## NO LEAK
==1031300== LEAK SUMMARY:
==1031300==    definitely lost: 0 bytes in 0 blocks
==1031300==    indirectly lost: 0 bytes in 0 blocks
==1031300==      possibly lost: 0 bytes in 0 blocks

For some context, I am running R4.2.2. My goal was to run valgrind on the
latest version of my spatPomp package. A memory leak was detected by
rhub::check_with_valgrind(). I then tracked down the problem by running
valgrind locally and in the end it seemed to come down to a problem with
png(). This was used in the spatPomp unit tests while testing the plot
method. I can use pdf() instead, but the point here is to report the issue
in case it is not known.

I'm new to R package development and happy to accept any advice.

Thanks,
Ed

Edward L. Ionides
Associate Chair for Undergraduate Studies and Professor,
Department of Statistics, University of Michigan
1085 South University, Ann Arbor, MI 48109-1107
email: ionides at umich.edu
phone: 734 615 3332
office: 453 West Hall

	[[alternative HTML version deleted]]

>>>>> Edward Ionides 
>>>>>     on Mon, 16 Jan 2023 09:04:49 -0500 writes:
    > Hi all,

    > Yesterday I discovered what seems to me like a memory leak in png() so
I'm
    > reporting it in case that is helpful. Here is a small reproducible
example:

    > R -d "valgrind --tool=memcheck --track-origins=yes
--leak-check=full"
    > --vanilla -e "png(filename='p.png'); plot(1:10);
dev.off()"
    > ## HAS LEAK
    > ==1021711== LEAK SUMMARY:
    > ==1021711==    definitely lost: 9,216 bytes in 30 blocks
    > ==1021711==    indirectly lost: 19,370 bytes in 838 blocks
    > ==1021711==      possibly lost: 3,868 bytes in 8 blocks

    > R -d "valgrind --tool=memcheck --track-origins=yes
--leak-check=full"
    > --vanilla -e "pdf(file='p.pdf'); plot(1:10);
dev.off()"
    > ## NO LEAK
    > ==1031300== LEAK SUMMARY:
    > ==1031300==    definitely lost: 0 bytes in 0 blocks
    > ==1031300==    indirectly lost: 0 bytes in 0 blocks
    > ==1031300==      possibly lost: 0 bytes in 0 blocks

I can reproduce, although I need to have the memcheck options in ~/.valgrindrc
The same happens if grid-based graphics is used and for the
latest R-devel :

R-devel -d valgrind --vanilla -e
'png("p.png");lattice::xyplot(1~1);dev.off()'

Using  png() shows leak
using  pdf()  is fine (0 bytes lost)


Looking at the full report (--leak-check=full  --track-origins=true
as 2 lines in ~/.valgrindrc ) I see several origins tracked to
internal malloc code,
but then also e.g.,

==1410108== 96 bytes in 1 blocks are possibly lost in loss record 700 of 3,037
==1410108==    at 0x484A464: calloc (vg_replace_malloc.c:1328)
==1410108==    by 0x159EA3A0: g_malloc0 (gmem.c:155)
==1410108==    by 0x15A3AB8C: g_rc_box_alloc_full.constprop.0 (grcbox.c:234)
==1410108==    by 0x1600A6C9: UnknownInlinedFun (pangofc-fontmap.c:899)
==1410108==    by 0x1600A6C9: UnknownInlinedFun (pangofc-fontmap.c:2145)
==1410108==    by 0x1600A6C9: pango_fc_font_map_load_fontset
(pangofc-fontmap.c:2245)
==1410108==    by 0x158E7474: UnknownInlinedFun (itemize.c:892)
==1410108==    by 0x158E7474: UnknownInlinedFun (itemize.c:952)
==1410108==    by 0x158E7474: pango_itemize_with_font (itemize.c:1564)
==1410108==    by 0x158FA89E: pango_layout_check_lines.part.0.lto_priv.0
(pango-layout.c:4894)
==1410108==    by 0x158EF4DB: UnknownInlinedFun (pango-layout.c:4786)
==1410108==    by 0x158EF4DB: pango_layout_get_line (pango-layout.c:1715)
==1410108==    by 0x1B5E441F: PG_text_extents (cairoFns.c:1487)
==1410108==    by 0x1B5E441F: PangoCairo_StrWidth (cairoFns.c:1565)
==1410108==    by 0x4CEBE6: GEStrWidth (engine.c:2615)
==1410108==    by 0x4CEBE6: GEStrWidth (engine.c:2578)
==1410108==    by 0x1BE12D11: textRect (util.c:198)
==1410108==    by 0x1BDFAF19: gridText (grid.c:3740)
==1410108==    by 0x1BE01FAB: L_textBounds (grid.c:3892)

which (from the bottom up) shows  package grid C code,
then R main but infrastructure for grDevices ("GEStrWidth (engine.c)")
and
subdirectory grDevices/src/cairo/cairoFns.c
and then goes into system cairo or pangocairo libraries,
which here (Linux Fedora 36) are (I thik)

	libpangocairo-1.0.so.0 
	libpango-1.0.so.0 

{as they are stripped, I don't know how to check }

To *fix* this I also have to defer to others.

Thank you for the report,
Martin

--
Martin Maechler
ETH Zurich  and  R Core team


    > For some context, I am running R4.2.2. My goal was to run valgrind on
the
    > latest version of my spatPomp package. A memory leak was detected by
    > rhub::check_with_valgrind(). I then tracked down the problem by running
    > valgrind locally and in the end it seemed to come down to a problem
with
    > png(). This was used in the spatPomp unit tests while testing the plot
    > method. I can use pdf() instead, but the point here is to report the
issue
    > in case it is not known.

    > I'm new to R package development and happy to accept any advice.

    > Thanks,
    > Ed

    > Edward L. Ionides
    > Associate Chair for Undergraduate Studies and Professor,
    > Department of Statistics, University of Michigan
    > 1085 South University, Ann Arbor, MI 48109-1107
    > email: ionides at umich.edu
    > phone: 734 615 3332
    > office: 453 West Hall

    > [[alternative HTML version deleted]]

    > ______________________________________________
    > R-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel