After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794209 - Memory leak when rendering color emoji
Memory leak when rendering color emoji
Status: RESOLVED NOTGNOME
Product: pango
Classification: Platform
Component: cairo
unspecified
Other Linux
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2018-03-09 15:49 UTC by my+gnomebugs
Modified: 2018-03-17 19:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple reproducer to test memory leak. (1.63 KB, text/x-csrc)
2018-03-09 15:49 UTC, my+gnomebugs
Details

Description my+gnomebugs 2018-03-09 15:49:30 UTC
Created attachment 369511 [details]
Simple reproducer to test memory leak.

Rendering color emoji causes a memory leak.

For testig purposes I use a simple FONTCONFIG_FILE that contains only font directories and a single match for emoji.

<fontconfig>
  <dir>/usr/share/fonts</dir>
  <match>
   <test name="family"><string>emoji</string></test>
   <edit name="family" mode="prepend"><string>Noto Color Emoji</string></edit>
   <edit name="color"><bool>true</bool></edit>
  </match>
</fontconfig>

If I disable color and render in black&white, then everything is fine.
   <edit name="color"><bool>false</bool></edit>

I checked the memory usage with memusage and the attached test. Black&white was stable at about 800k, while the color emoji was rising in a linear fashion.

memusage -T -p /tmp/emoji-memusage ./emojitest /tmp/emoji-color.png 10000 '<color emoji, e.g. U+1F600>'

my test environment:
Arch Linux
kernel 4.15.7-1-ARCH
pango-git 1.41.1.3991.505eeb7b-1
cairo 1.15.10-1
freetype2 2.9-2
fontconfig 2.12.6+5+g665584a-1

The leak is present in pango 1.40.14-2 as well
Comment 1 Khaled Hosny 2018-03-17 19:33:50 UTC
Running under valgrind shows leaks inside Cairo:

==20357== 1,280,000 bytes in 10,000 blocks are definitely lost in loss record 702 of 702
==20357==    at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==20357==    by 0x584955F: cairo_pattern_create_for_surface (in /usr/lib/libcairo.so.2.11510.0)
==20357==    by 0x58691B8: ??? (in /usr/lib/libcairo.so.2.11510.0)
==20357==    by 0x586B887: ??? (in /usr/lib/libcairo.so.2.11510.0)
==20357==    by 0x5827882: ??? (in /usr/lib/libcairo.so.2.11510.0)
==20357==    by 0x5818C03: cairo_show_glyphs (in /usr/lib/libcairo.so.2.11510.0)
==20357==    by 0x4E4193A: pango_cairo_renderer_show_text_glyphs.isra.3 (pangocairo-render.c:531)
==20357==    by 0x4E41B53: pango_cairo_renderer_draw_glyph_item (pangocairo-render.c:576)
==20357==    by 0x507165D: pango_renderer_draw_glyph_item (pango-renderer.c:718)
==20357==    by 0x50720F0: pango_renderer_draw_layout_line (pango-renderer.c:572)
==20357==    by 0x50724C4: pango_renderer_draw_layout (pango-renderer.c:196)
==20357==    by 0x4E41E49: _pango_cairo_do_layout (pangocairo-render.c:1041)

So does not seem like a Pango bug. These leaks are not present when using Cairo master, so looks like a leak that was fixed in Cairo.