memory leak in png()
On 17/01/2023 13:06, Duncan Murdoch wrote:
I don't have a valgrind-capable version of R, but I'd be interested to
see whether this is a one-time loss, or repeated.? That is, do you get a
much bigger loss from running the lossy code in a loop like this?
?for (i in 1:100) { png(filename='p.png'); plot(1:10); dev.off() }
Duncan Murdoch
Duncan - Not that I'm seeing
Rdevel -d valgrind --vanilla -e " for (i in 1:1) {png(filename='p.png');
plot(1:10); dev.off()}"
==63291== LEAK SUMMARY:
==63291== definitely lost: 2,560 bytes in 4 blocks
==63291== indirectly lost: 17,710 bytes in 762 blocks
==63291== possibly lost: 1,820 bytes in 8 blocks
==63291== still reachable: 52,177,408 bytes in 21,282 blocks
==63291== of which reachable via heuristic:
==63291== newarray : 4,264 bytes in 1
blocks
==63291== suppressed: 0 bytes in 0 blocks
Rdevel -d valgrind --vanilla -e " for (i in 1:100)
{png(filename='p.png'); plot(1:10); dev.off()}"
==63464== LEAK SUMMARY:
==63464== definitely lost: 2,560 bytes in 4 blocks
==63464== indirectly lost: 17,710 bytes in 762 blocks
==63464== possibly lost: 1,820 bytes in 8 blocks
==63464== still reachable: 56,072,939 bytes in 19,283 blocks
==63464== of which reachable via heuristic:
==63464== newarray : 4,264 bytes in 1
blocks
==63464== suppressed: 0 bytes in 0 blocks
Tim
On 17/01/2023 4:55 a.m., Martin Maechler wrote:
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
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel