GNOME Bugzilla – Bug 770241
GeglBuffer leaks when using GIMP to cut a selection
Last modified: 2018-05-24 16:48:38 UTC
Using GIMP 2.9.5, commit d13bc78, make a new file, make a selection, then do "Edit/Cut", and then close the file and close GIMP. A message is printed to the terminal saying: EEEEeEeek! 1 GeglBuffers leaked To debug GeglBuffer leaks, set the environment variable GEGL_DEBUG to "buffer-alloc". I wasn't able to get any edits not including "select" followed by "cut" to trigger the leak. I set the environmental variable and reran GIMP, repeating the procedure, with following terminal output: Leaked buffer allocation stack trace: Leaked buffer allocation stack trace: install/lib/libgegl-0.3.so.0(+0x30cea)[0x7f405c24ccea] install/lib/libgobject-2.0.so.0(g_type_create_instance+0x2c3)[0x7f405a276ff5] install/lib/libgobject-2.0.so.0(+0x13ace)[0x7f405a259ace] install/lib/libgegl-0.3.so.0(+0x31202)[0x7f405c24d202] install/lib/libgobject-2.0.so.0(+0x13de5)[0x7f405a259de5] install/lib/libgobject-2.0.so.0(g_object_new_valist+0x4dd)[0x7f405a25bd92] install/lib/libgobject-2.0.so.0(g_object_new+0xf2)[0x7f405a25bf26] install/lib/libgegl-0.3.so.0(gegl_buffer_new+0x76)[0x7f405c24de36] install/bin/gimp-2.9(gimp_selection_extract+0x370)[0x839c80] install/bin/gimp-2.9[0x762a9a] install/bin/gimp-2.9(gimp_edit_cut+0x17e)[0x762d9e] install/bin/gimp-2.9(edit_cut_cmd_callback+0x5c)[0x4a677c] install/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x66)[0x7f405a256ab3] install/lib/libgobject-2.0.so.0(g_closure_invoke+0x189)[0x7f405a254ffe] install/lib/libgobject-2.0.so.0(+0x20e9f)[0x7f405a266e9f] install/lib/libgobject-2.0.so.0(g_signal_emit_valist+0xdd7)[0x7f405a26f34c] install/lib/libgobject-2.0.so.0(g_signal_emit+0x97)[0x7f405a26f7e3] /usr/lib64/libgtk-x11-2.0.so.0(+0x73620)[0x7f405edfe620] install/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOIDv+0x30)[0x7f405a256ae8] install/lib/libgobject-2.0.so.0(+0xd640)[0x7f405a253640] install/lib/libgobject-2.0.so.0(+0xf240)[0x7f405a255240] install/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x4f8)[0x7f405a26ea6d] install/lib/libgobject-2.0.so.0(g_signal_emit+0x97)[0x7f405a26f7e3] /usr/lib64/libgtk-x11-2.0.so.0(gtk_widget_activate+0x76)[0x7f405efd22a6] /usr/lib64/libgtk-x11-2.0.so.0(gtk_menu_shell_activate_item+0xfd)[0x7f405eece3dd] /usr/lib64/libgtk-x11-2.0.so.0(+0x14377b)[0x7f405eece77b] /usr/lib64/libgtk-x11-2.0.so.0(+0x1314af)[0x7f405eebc4af] install/lib/libgobject-2.0.so.0(+0xd7b4)[0x7f405a2537b4] install/lib/libgobject-2.0.so.0(g_closure_invoke+0x189)[0x7f405a254ffe] install/lib/libgobject-2.0.so.0(+0x21305)[0x7f405a267305] install/lib/libgobject-2.0.so.0(g_signal_emit_valist+0xe39)[0x7f405a26f3ae] install/lib/libgobject-2.0.so.0(g_signal_emit+0x97)[0x7f405a26f7e3] /usr/lib64/libgtk-x11-2.0.so.0(+0x24851c)[0x7f405efd351c] /usr/lib64/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc4)[0x7f405eebabf4] /usr/lib64/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3ab)[0x7f405eebb08b] /usr/lib64/libgdk-x11-2.0.so.0(+0x5b2ec)[0x7f405eb302ec] install/lib/libglib-2.0.so.0(g_main_context_dispatch+0x29a)[0x7f4059d7e0ea] install/lib/libglib-2.0.so.0(+0x472ba)[0x7f4059d7e2ba] install/lib/libglib-2.0.so.0(g_main_loop_run+0x14b)[0x7f4059d7e61e] install/bin/gimp-2.9(app_run+0x29a)[0x48c6aa] install/bin/gimp-2.9(main+0x301)[0x48c041] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f4058fc6620] install/bin/gimp-2.9(_start+0x29)[0x48c209] EEEEeEeek! 1 GeglBuffers leaked
GEGL is just the messenger of the leak here - going over all still existing buffers on exit and reporting where they were allocated.
I can't reproduce this, no buffer leaks reported no matter how I cut and then close image and GIMP. Is there anything special about your GIMP you can think of (patches, whatever)?
(In reply to Michael Natterer from comment #2) > I can't reproduce this, no buffer leaks reported no matter how I cut > and then close image and GIMP. Is there anything special about your GIMP > you can think of (patches, whatever)? It would be very inappropriate if I reported a bug against anything other than default GIMP :) . I just verified the leak is still there (default babl/GEGL/GIMP rebuilt yesterday). Tomorrow I'll check to see if maybe it's a particular file type that causes the problem.
I just tried to reproduce this again with all sorts of dockables open (which often reference stuff), still no luck. Could you try the following please: 1. save your sessionrc away 2. reproduce the leak 3. close one dockable 4. repeat from 2. Until the leak goes away, then tell me the dockable you closed before the leak went away?
Hmm, sorry, I closed all the dockers all one by one, and then removed all the tools from the toolbox, and then even closed the toolbox, each time restarting GIMP. And the leak remains. The problem extends to copy, and sometimes causes issues with paste. But "clear" instead of "cut" doesn't cause the gegl buffer leak. I normally use a script to start GIMP, as follows: #! /bin/bash PREFIX=$HOME/code/gimpdefault/install export PATH=$PREFIX/bin:$PATH export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS export XDG_CACHE_HOME=/home/elle/.cache export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal" export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig" export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export GIO_EXTRA_MODULES=/usr/lib/gio/modules export SRC_DIR=$HOME/code/gimpdefault/build export TMPDIR=/tmp GEGL_USE_OPENCL=no export GEGL_USE_OPENCL GEGL_SWAP=TMP export GEGL_SWAP GEGL_DEBUG=buffer-alloc export GEGL_DEBUG $PREFIX/bin/gimp-2.9 -n$@ If I don't use the script to start GIMP, and instead cd to $PREFIX/bin and type "./gimp-2.9", the only thing unusual printed to screen is "EEEEeEeek! 1 GeglBuffers leaked". But if I start GIMP using the script, the following is printed to terminal (this new stuff only appeared after the latest updates to GIMP, I don't know when the gegl buffer itself might have appeared, but it was awhile back): Leaked buffer allocation stack trace: /home/elle/code/gimpdefault/install/lib/libgegl-0.3.so.0(+0x30cea)[0x7ff49f237cea] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_type_create_instance+0x1f9)[0x7ff49cfedb69] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(+0x14b48)[0x7ff49cfcfb48] /home/elle/code/gimpdefault/install/lib/libgegl-0.3.so.0(+0x31202)[0x7ff49f238202] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(+0x14e24)[0x7ff49cfcfe24] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_object_new_valist+0x3c5)[0x7ff49cfd1cd5] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_object_new+0xf9)[0x7ff49cfd2019] /home/elle/code/gimpdefault/install/lib/libgegl-0.3.so.0(gegl_buffer_new+0x76)[0x7ff49f238e36] /home/elle/code/gimpdefault/install/bin/gimp-2.9(gimp_selection_extract+0x35e)[0x77d97e] /home/elle/code/gimpdefault/install/bin/gimp-2.9[0x6e5e23] /home/elle/code/gimpdefault/install/bin/gimp-2.9(gimp_edit_copy+0x17b)[0x6e62bb] /home/elle/code/gimpdefault/install/bin/gimp-2.9(edit_copy_cmd_callback+0x5c)[0x4a67fc] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_closure_invoke+0x145)[0x7ff49cfca945] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(+0x22466)[0x7ff49cfdd466] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x1009)[0x7ff49cfe6239] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_signal_emit+0x97)[0x7ff49cfe64a7] /usr/lib64/libgtk-x11-2.0.so.0(+0x73620)[0x7ff4a1b6c620] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(+0xfb74)[0x7ff49cfcab74] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8fa)[0x7ff49cfe5b2a] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_signal_emit+0x97)[0x7ff49cfe64a7] /usr/lib64/libgtk-x11-2.0.so.0(gtk_widget_activate+0x76)[0x7ff4a1d402a6] /usr/lib64/libgtk-x11-2.0.so.0(gtk_menu_shell_activate_item+0xfd)[0x7ff4a1c3c3dd] /usr/lib64/libgtk-x11-2.0.so.0(+0x14377b)[0x7ff4a1c3c77b] /usr/lib64/libgtk-x11-2.0.so.0(+0x1314af)[0x7ff4a1c2a4af] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_closure_invoke+0x145)[0x7ff49cfca945] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(+0x2235f)[0x7ff49cfdd35f] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_signal_emit_valist+0xaf8)[0x7ff49cfe5d28] /home/elle/code/gimpdefault/install/lib/libgobject-2.0.so.0(g_signal_emit+0x97)[0x7ff49cfe64a7] /usr/lib64/libgtk-x11-2.0.so.0(+0x24851c)[0x7ff4a1d4151c] /usr/lib64/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc4)[0x7ff4a1c28bf4] /usr/lib64/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3ab)[0x7ff4a1c2908b] /usr/lib64/libgdk-x11-2.0.so.0(+0x5b2ec)[0x7ff4a189e2ec] /home/elle/code/gimpdefault/install/lib/libglib-2.0.so.0(g_main_context_dispatch+0x24d)[0x7ff49caebf2d] /home/elle/code/gimpdefault/install/lib/libglib-2.0.so.0(+0x4a210)[0x7ff49caec210] /home/elle/code/gimpdefault/install/lib/libglib-2.0.so.0(g_main_loop_run+0xc2)[0x7ff49caec532] /home/elle/code/gimpdefault/install/bin/gimp-2.9(app_run+0x2a2)[0x48f612] /home/elle/code/gimpdefault/install/bin/gimp-2.9(main+0x301)[0x48efc1] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7ff49bd31620] /home/elle/code/gimpdefault/install/bin/gimp-2.9(_start+0x29)[0x48f169] EEEEeEeek! 1 GeglBuffers leaked
(In reply to Elle Stone from comment #5) > The problem extends to copy, and sometimes causes issues with paste. But > "clear" instead of "cut" doesn't cause the gegl buffer leak. > > I normally use a script to start GIMP, as follows: > #! /bin/bash > GEGL_DEBUG=buffer-alloc > export GEGL_DEBUG > $PREFIX/bin/gimp-2.9 -n$@ > But if I start GIMP using the script, the following is printed to terminal > (this new stuff only appeared after the latest updates to GIMP, I don't know > when the gegl buffer itself might have appeared, but it was awhile back): > Hmm, on second glance, the new stuff is from adding GEGL_DEBUG=buffer-alloc export GEGL_DEBUG to the script. Sorry!
Hmm, another person checked the same procedure and wasn't able to trigger the terminal warning. Maybe this is just something odd about my installation.
Do you still get this?
Yes, on Gentoo (GIMP updated today) and also on Debian testing (GIMP updated maybe a week or so ago). Maybe there is something odd/wrong/different about the way I'm building GIMP?
For info, I don't get such warnings either. Do you still get it? Which options are you building GIMP with?
Exactly following the procedure in the first post: ~/code/gimpdefault/build/gimp $ ../../rungimpdefault This is a development version of GIMP. Debug messages may appear here. Missing fast-path babl conversion detected, Implementing missing babl fast paths accelerates GEGL, GIMP and other software using babl, warnings are printed on first occurance of formats used where a conversion has to be synthesized programmatically by babl based on format description Exactly following the steps from the initial post: *WARNING*: missing babl fast path(s) between formats "CIE LCH(ab) double" and "R'G'B' double" GIMP-Error: Failed to load data: Error loading '/usr/share/mypaint/brushes/deevad/thin_watercolor.myb': Failed to deserialize MyPaint brush. gimp_display_shell_profile_update gimp_display_shell_profile_update gimp_display_shell_profile_update gimp_display_shell_profile_update src_profile: GIMP built-in Linear sRGB src_format: RGBA float dest_format: R'G'B'A float gimp_display_shell_profile_update src_profile: GIMP built-in Linear sRGB src_format: RGBA float dest_format: R'G'B'A float gimp_display_shell_profile_update src_profile: GIMP built-in Linear sRGB src_format: RGBA float dest_format: R'G'B'A float *WARNING*: missing babl fast path(s) between formats "RGBA float" and "A u8" gimp_display_shell_profile_update EEEEeEeek! 1 GeglBuffers leaked elle@localhost ~/code/gimpdefault/build/gimp $ This is on Gentoo updated a couple of days ago, babl/GEGL/GIMP updated and recompiled this morining. Setting up the prefix: PREFIX=$HOME/code/gimpdefault/install export PATH=$PREFIX/bin:$PATH export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS export XDG_CACHE_HOME=/home/elle/.cache export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal" export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH export GIO_EXTRA_MODULES=/usr/lib/gio/modules export SRC_DIR=$HOME/code/gimpdefault/build export TMPDIR=/tmp Compiling GIMP: cd $SRC_DIR/gimp make -j4 uninstall make -j4 clean git clean -xdf git status ./autogen.sh --prefix=$PREFIX --disable-gtk-doc --enable-debug=yes --with-gimpdir=$PREFIX/config make -j4 > /dev/null && make -j4 install > /dev/null "clear" instead of "cut" doesn't cause the gegl leak message: $ ../../rungimpdefault This is a development version of GIMP. Debug messages may appear here. Missing fast-path babl conversion detected, Implementing missing babl fast paths accelerates GEGL, GIMP and other software using babl, warnings are printed on first occurance of formats used where a conversion has to be synthesized programmatically by babl based on format description *WARNING*: missing babl fast path(s) between formats "CIE LCH(ab) double" and "R'G'B' double" GIMP-Error: Failed to load data: Error loading '/usr/share/mypaint/brushes/deevad/thin_watercolor.myb': Failed to deserialize MyPaint brush. gimp_display_shell_profile_update gimp_display_shell_profile_update gimp_display_shell_profile_update gimp_display_shell_profile_update src_profile: GIMP built-in Linear sRGB src_format: RGBA float dest_format: R'G'B'A float gimp_display_shell_profile_update src_profile: GIMP built-in Linear sRGB src_format: RGBA float dest_format: R'G'B'A float gimp_display_shell_profile_update src_profile: GIMP built-in Linear sRGB src_format: RGBA float dest_format: R'G'B'A float gimp_display_shell_profile_update elle@localhost ~/code/gimpdefault/build/gimp $ If no one else can replicate the bug, I don't mind if it's closed.
Hello Elle, I was wondering if you were still encountering this leak warning with a recent tree?
Hi Jehan, Checking with code updated through January 15, 2018, yes. Here's the terminal output on closing GIMP: (gimp-2.9:5492): GEGL-WARNING **: 09:04:41.653: (gegl-tile-handler-cache.c:836):gegl_tile_cache_destroy: runtime check failed: (g_queue_is_empty (&cache_queue)) EEEEeEeek! 1 GeglBuffers leaked
Created attachment 367498 [details] [review] DO NOT COMMIT - Force clear clipboard on exit Reproduced on: Windows 7 SP1 64-bit 2.9.8 wgo installer Windows XP SP3 32-bit 2.9.9 commit de52cbf This behavior occurs on Windows as well, caused when gimp's clipboard is not freed on exit. Following are some simplified run logs, with the actions I took in [brackets]. Notice that gimp_dispose() and gimp_finalize() are not run when there are buffers in the clipboard. $ gimp-2.9.exe --verbose INIT: gimp_load_config INIT: gimp_initialize INIT: gimp_real_initialize INIT: gui_initialize_after_callback INIT: gimp_restore INIT: gui_restore_callback INIT: gimp_real_restore INIT: gui_restore_after_callback [ Quit ] EXIT: gimp_exit EXIT: gui_exit_callback EXIT: gimp_real_exit EXIT: gui_exit_after_callback EXIT: app_exit_after_callback EXIT: gimp_dispose EXIT: gimp_finalize $ gimp-2.9.exe --verbose INIT: ... [ New, Select All, Copy, Quit ] EXIT: gimp_exit EXIT: gui_exit_callback EXIT: gimp_real_exit EXIT: gui_exit_after_callback EXIT: app_exit_after_callback (gimp-2.9.exe:3000): GEGL-WARNING **: (N:/git/gegl/gegl/buffer/gegl-tile-handler-cache.c:836):gegl_tile_cache_destroy: runtime check failed: (g_queue_is_empty (&cache_queue)) To debug GeglBuffer leaks, set the environment variable GEGL_DEBUG to "buffer-alloc" EEEEeEeek! 1 GeglBuffers leaked $ gimp-2.9.exe --verbose INIT: ... [ New, Copy (the whole layer), Quit ] EXIT: gimp_exit EXIT: gui_exit_callback EXIT: gimp_real_exit EXIT: gui_exit_after_callback EXIT: app_exit_after_callback (gimp-2.9.exe:3000): GEGL-WARNING **: (N:/git/gegl/gegl/buffer/gegl-tile-handler-cache.c:836):gegl_tile_cache_destroy: runtime check failed: (g_queue_is_empty (&cache_queue)) To debug GeglBuffer leaks, set the environment variable GEGL_DEBUG to "buffer-alloc" EEEEeEeek! 4 GeglBuffers leaked Just as a test, modifying gimp_exit() to clear the clipboard (see patch) eliminates the leaks. Elle, to be sure this is the same bug, can you confirm: 1) Four buffers are leaked when copying the current layer vs a selection 2) With image data in the clipboard, `gimp-2.9 --verbose` shows gimp_dispose or gimp_finalize not being run 3) Applying my patch eliminates these buffer leaks I hope this helps someone narrow it down. Sadly, I can't get a useful stack trace on Windows.
(In reply to Edward E. from comment #14) > Elle, to be sure this is the same bug, can you confirm: > 1) Four buffers are leaked when copying the current layer vs a selection Yes - 4 buffers leak when copying the layer, 1 when copying a selection. > 2) With image data in the clipboard, `gimp-2.9 --verbose` shows > gimp_dispose or gimp_finalize not being run Yes, neither of these functions are run. > 3) Applying my patch eliminates these buffer leaks Yes, applying the patch eliminates the buffer leaks. Thank you! for looking into this. I wonder if the reason most people don't see the leaks is perhaps because most people have some sort of clip-board manager installed, in addition to whatever GIMP itself supplies?
Thanks guys for the analysis! This brings up the problem of "why is the main GIMP object never" finalized. It's finalized here just fine. So the real leak is that we somehow leak a reference, and it happens because of whatever is different on your machines (e.g. special dialog open, ...).
Grokking the code, I find that the main gimp object is supposed to be ref'ed during copy when GIMP calls gtk_clipboard_set_can_store(), and unref'ed (presumably on app exit) by the private gtk_clipboard_finalize(). It is also unref'd when gimp contents of the gtk clipboard are overwritten, which explains why copying to the clipboard from outside GIMP after a GIMP copy operation enables GIMP to exit properly. (I forgot to mention this behavior earlier.) However, setting breakpoints in gdb shows that although gtk_clipboard_class_init() is called at startup, gtk_clipboard_finalize() is never called on Windows. Perhaps it's getting hung up in platform specific gdk code? When is the gtk clipboard class supposed to be finalized? As for Linux, I would wager that Elle doesn't have the same desktop/window manager as Michael or Jehan. I couldn't find anything wrong with GIMP's or GTK's clipboard code, but that doesn't really prove anything. :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/949.