>>>>> 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: ioni...@umich.edu > phone: 734 615 3332 > office: 453 West Hall > [[alternative HTML version deleted]] > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel