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 699625 - Gimp memory leak when jdownloader is also running
Gimp memory leak when jdownloader is also running
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.8.4
Other Linux
: Normal major
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 697443 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-05-03 19:42 UTC by Stelios R.
Modified: 2018-05-24 13:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stelios R. 2013-05-03 19:42:34 UTC
When both GIMP and jdownloader are running, gimp memory usage increases rapidly until the system runs out of memory. The system then freezes.

In order to reproduce this bug, launch jdownloader (you do need to download anything) and then launch GIMP. Load an .xcf file, preferably a rather big one with many layers. The mouse pointer will usually start flickering at this point. Now use the erase tool. You may have to use the tool two or three times. Soon after, GIMP memory usage will start to increase rapidly, even if you do not do anything, until the system runs out of memory. Shutting down jdownloader will halt the memory leak, but GIMP will not release the extra memory. 

The bug appears in Debian Testing 64 bit and Linux Mint 13 64 bit. It was present in GIMP 2.6 as well. I have not tested the above bug in any other distributions, so i do not know if it appears there as well.
Comment 1 Michael Schumacher 2013-05-03 19:56:16 UTC
Did you ask the jdownloader developers if they have an idea why this might be happening?
Comment 2 Stelios R. 2013-05-03 20:25:23 UTC
No, i haven't (yet). Mostly because it is GIMP that increases its memory usage until the system  runs out of memory in this situation, not jdownloader, so i decided to report it here first.
Comment 3 Stelios R. 2013-05-03 21:17:25 UTC
I just reported the bug to the jdownloader developers as well.

http://board.jdownloader.org/showthread.php?p=252720#post252720
Comment 4 Michael Schumacher 2013-05-04 16:54:44 UTC
BTW, as suspected, this sort of software comes with the usual unwanted by-pack:
http://board.jdownloader.org/showthread.php?t=44832

So you should check if any of the troja^wtoolbars or other utilities you got is responsible for that behavior. Maybe something is grabbing the mouse pointer to check what you click on.
Comment 5 Stelios R. 2013-05-05 01:09:48 UTC
I run Linux, not Window$. I can see exactly what is running on my system and there aren't any processes there, other the ones i want, one by one.
Comment 6 Stelios R. 2013-05-06 02:26:50 UTC
I made a youtube video to show the problem.

http://www.youtube.com/watch?v=Adx4P0Bxo00

As you can see, it seems as if the layer i copied, keeps getting copied to the clipboard, over and over until the system runs out of memory. It only happens  when JDownloader is also running. Other programs are not affected.
Comment 7 Michael Schumacher 2013-05-06 07:36:40 UTC
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573113

I wonder if GIMP should be doing something else, or JDownloader. 

The thread in your from mentions a possible bug in Photoshop what exhibited the same symptoms, but given that that software is closed source we will never know whether they just added a workaround (e.g. "if jdownloader is running, don't bother to update the clipboard-based stuff in our app"). Looking at this in floss software on both ends might finally shed light on the actual cause.

In the meantime, disable the link grabbing.
Comment 8 Stelios R. 2013-05-06 14:19:16 UTC
Yes, by disabling JD clipboard monitoring the problem disappears.
Comment 9 Michael Schumacher 2013-05-07 12:41:49 UTC
From the jdownloader forum thread:

<+jiaz> its a gimp issue
<+jiaz> Toolkit.getDefaultToolkit().getSystemClipboard().getContents(null)
<+jiaz> gimp is preparing the content of clipboard but not freeing it again
<+jiaz> grabbing content of clipboard = gimp will create new content, not free old one
<+jiaz> every time
Comment 10 Michael Natterer 2013-05-07 19:35:03 UTC
I can reproduce exactly the same symptoms (ever increasing memory consumption
without any user interaction) when I copy something in gimp, and then
repeatedly launch:

tools/test-clipboard -t image/png -p /tmp/foo.png

And abort it by crtl+c. If I don't abort, GIMP's memory consumption doesn't
change at all. If I try aborting often enough, something gets into a loop
(and it's probably not GIMP), and consumes insane amounts of memory.

At some point, this warning happens over and over again:

(gimp-2.9:5354): Gdk-CRITICAL **: IA__gdk_window_get_events: assertion `GDK_IS_WINDOW (window)' failed

The stack trace is:

  • #0 g_logv
    at gmessages.c line 981
  • #1 g_log
    at gmessages.c line 1010
  • #2 g_return_if_fail_warning
  • #3 IA__gdk_window_get_events
    at gdkwindow.c line 7358
  • #4 IA__gdk_window_get_events
    at gdkwindow.c line 7354
  • #5 _gtk_selection_request
    at gtkselection.c line 2449
  • #6 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 86
  • #7 g_type_class_meta_marshal
    at gclosure.c line 970
  • #8 g_closure_invoke
    at gclosure.c line 777
  • #9 signal_emit_unlocked_R
    at gsignal.c line 3622
  • #10 g_signal_emit_valist
    at gsignal.c line 3338
  • #11 g_signal_emit
    at gsignal.c line 3384
  • #12 gtk_widget_event_internal
    at gtkwidget.c line 5010
  • #13 IA__gtk_widget_event
    at gtkwidget.c line 4807
  • #14 IA__gtk_main_do_event
    at gtkmain.c line 1639
  • #15 gdk_event_dispatch
    at gdkevents-x11.c line 2403
  • #16 g_main_dispatch
    at gmain.c line 3058
  • #17 g_main_context_dispatch
    at gmain.c line 3634
  • #18 g_main_context_iterate
    at gmain.c line 3705
  • #19 g_main_loop_run
    at gmain.c line 3899
  • #20 app_run
    at app.c line 256
  • #21 main
    at main.c line 438

Which involves _gtk_selection_request() in frame #5.

To me it looks like the aborted selection operation messes up things. This
is clearly a bug in GIMP/GTK+/whatever and should be fixed, but couldn't
jdownloader be changed not to do this?
Comment 11 Michael Schumacher 2013-05-18 09:55:37 UTC
*** Bug 697443 has been marked as a duplicate of this bug. ***
Comment 12 Øyvind Stegard 2014-07-22 20:11:01 UTC
I'm seeing similar strange interactions between Gimp and Netbeans (also a Java-app). If both programs run simultaneously Gimp can start consuming huge amounts of memory and CPU whenever I highlight and jump between files in the Netbeans file explorer. It also causes slugishness in Netbeans (Gimp CPU usage is rather high while interacting with Netbeans). The memory is never freed by Gimp. In one instance I killed Gimp after it reached 11GB of memory usage, system has 16GB.

- Gimp v2.8.10, Ubuntu 14.04 x86-64.
- Netbeans 8 running on Oracle JVM 1.7.0_65.

Bottom line: this is not just a problem together with jdownloader. Might be more generic with Java-based Swing apps or something.
Comment 13 Michael Schumacher 2014-07-22 20:13:35 UTC
You could ask the Netbeans developers if they grab clipboard like jodownloader.
Comment 14 GNOME Infrastructure Team 2018-05-24 13:42:03 UTC
-- 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/471.