I have the same problem Mint 18/Ubuntu 16.04
but it only happens when I access the signals tab and add a signal. RAM is filled the swap is filled then the system crashes.

(In reply to Mark from comment #1)
> I have the same problem Mint 18/Ubuntu 16.04
> but it only happens when I access the signals tab and add a signal. RAM is
> filled the swap is filled then the system crashes.

Ok good this is getting somewhere.

I can not reproduce on glade master, so I will need you to be more specific with the exact steps to reproduce this.

BTW whats you glade and gtk versions?

Also a backtrace/valgrind log would not hurt :D

Distro: Linux Mint 18 (ubuntu 16.04)
Gtk: libgtk-3-0 3.18.9-1ubuntu3.1
Glade:  glade, libgladeui, libgladeui-common all = 3.18.3-1
(note glade version 3.20 will not build without up dates to other packages.
I am not keen to update other core packages)

Steps:
Run Glade
add window
add button
at this stage I think there is no problem
add the on_click signal.  
This is were the problem starts. Not saved at this point.

Its a very long time since I have used backtrace 
so if this is not what you need give me the exact steps.


Starting program: /usr/local/bin/glade 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb2ef700 (LWP 21578)]
[New Thread 0x7fffeaaee700 (LWP 21579)]
[New Thread 0x7fffea085700 (LWP 21581)]
[New Thread 0x7fffe9884700 (LWP 21582)]
[New Thread 0x7fffe9083700 (LWP 21583)]
[New Thread 0x7fffe8882700 (LWP 21584)]
[New Thread 0x7fffd36db700 (LWP 21585)]
[New Thread 0x7fffd2c92700 (LWP 21586)]
[Thread 0x7fffe8882700 (LWP 21584) exited]
[Thread 0x7fffe9083700 (LWP 21583) exited]
[Thread 0x7fffe9884700 (LWP 21582) exited]
[Thread 0x7fffea085700 (LWP 21581) exited]
[New Thread 0x7fffe9083700 (LWP 21591)]
[New Thread 0x7fffea085700 (LWP 21592)]
[New Thread 0x7fffe8882700 (LWP 21593)]
[New Thread 0x7fffe9884700 (LWP 21594)]
[New Thread 0x7fffd1584700 (LWP 21595)]
[New Thread 0x7fffd0d83700 (LWP 21596)]
[Thread 0x7fffe8882700 (LWP 21593) exited]
[Thread 0x7fffd0d83700 (LWP 21596) exited]
[Thread 0x7fffd1584700 (LWP 21595) exited]
[Thread 0x7fffea085700 (LWP 21592) exited]
[Thread 0x7fffe9083700 (LWP 21591) exited]
[Thread 0x7fffd36db700 (LWP 21585) exited]
[Thread 0x7fffe9884700 (LWP 21594) exited]
[New Thread 0x7fffe9884700 (LWP 21599)]
[New Thread 0x7fffd36db700 (LWP 21600)]
[New Thread 0x7fffd0d83700 (LWP 21601)]
[New Thread 0x7fffe9083700 (LWP 21602)]
[New Thread 0x7fffe8882700 (LWP 21603)]
[Thread 0x7fffd36db700 (LWP 21600) exited]
[Thread 0x7fffd0d83700 (LWP 21601) exited]
[Thread 0x7fffe9884700 (LWP 21599) exited]
[Thread 0x7fffe8882700 (LWP 21603) exited]
[New Thread 0x7fffe8882700 (LWP 21605)]
[Thread 0x7fffe8882700 (LWP 21605) exited]
[New Thread 0x7fffe8882700 (LWP 21606)]
[Thread 0x7fffe9083700 (LWP 21602) exited]
[New Thread 0x7fffe9083700 (LWP 21607)]
[Thread 0x7fffe8882700 (LWP 21606) exited]
[New Thread 0x7fffe8882700 (LWP 21608)]
[Thread 0x7fffe8882700 (LWP 21608) exited]
[New Thread 0x7fffe8882700 (LWP 21609)]
[Thread 0x7fffe8882700 (LWP 21609) exited]
[New Thread 0x7fffe8882700 (LWP 21610)]
[Thread 0x7fffe8882700 (LWP 21610) exited]
[New Thread 0x7fffe8882700 (LWP 21611)]
[Thread 0x7fffe8882700 (LWP 21611) exited]
[New Thread 0x7fffe8882700 (LWP 21612)]
[Thread 0x7fffe8882700 (LWP 21612) exited]
[New Thread 0x7fffe8882700 (LWP 21613)]
[Thread 0x7fffe8882700 (LWP 21613) exited]
[New Thread 0x7fffe8882700 (LWP 21614)]
[Thread 0x7fffe8882700 (LWP 21614) exited]
[New Thread 0x7fffe8882700 (LWP 21615)]
[Thread 0x7fffe8882700 (LWP 21615) exited]
[New Thread 0x7fffe8882700 (LWP 21616)]
[Thread 0x7fffe8882700 (LWP 21616) exited]
[Thread 0x7fffe9083700 (LWP 21607) exited]

Thread 1 "glade" received signal SIGINT, Interrupt.
0x00007ffff5a3fc81 in __memcmp_sse4_1 ()
    at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:56
56	../sysdeps/x86_64/multiarch/memcmp-sse4.S: No such file or directory.

+ Trace 236607

Hope this helps.

Mark, I guess it needs debugging symbols. If so, you need to locate in your repos the corresponding debugging symbols package for Glade, and then install it. Once done, repeating the backtrace as you have done it will reveal more precise information about where it is crashing.

Regards!

Created attachment 343344 [details]
ui file that show the problem

Here's a test .ui file to show high CPU usage on glade and X11 processes.

The CPU load will drop if the `checkbutton` in the headerbar is un-checked.

I had the same problem several times with Glade 3.18.3 on Ubuntu 16.04: after making some changes to my Glade file  or  navigating quickly in the widget tree,  a CPU core gets 100 % busy and RAM  continuously goes up until system freeze.

I checked the Glade preferences (Menu: Edit > Preferences) and noticed that under "Load and Save" the option "Automatically save project after ..." was set to 5 seconds by default. This value seems to lead to high memory consumption or endless loops. 
After deactivating this option the system remains stable.

Created attachment 343482 [details]
Glade editor when system becomes unstable

After some more testing on this unfortunately the workaround above seems not to help.

I can now reproduce the freeze with 2 clicks: after start of Glade choose the window widget and click on 'signals' tab. Then wait until the system is freezed (see attachment).
I hope this will be helpful.

If I do a
    `GTK_DEBUG=all glade`

When I load the problem .ui file with checked checkbottuon, the design area was repaint repeatedly like crazy.

And DEBUG print out the following messages forever:


Gtk-Message: [0x558beaa1fad0] GtkScrollbar	height for width: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: [0x558beaa1fcd0] GtkScrollbar	width for height: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: Symbolic icon /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg is not in an icon theme directory
Gtk-Message: [0x558beaa1fad0] GtkScrollbar	height for width: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: [0x558beaa1fcd0] GtkScrollbar	width for height: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: Symbolic icon /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg is not in an icon theme directory
Gtk-Message: [0x558beaa1fad0] GtkScrollbar	height for width: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: [0x558beaa1fcd0] GtkScrollbar	width for height: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: Symbolic icon /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg is not in an icon theme directory
Gtk-Message: [0x558beaa1fad0] GtkScrollbar	height for width: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: [0x558beaa1fcd0] GtkScrollbar	width for height: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: Symbolic icon /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg is not in an icon theme directory
Gtk-Message: [0x558beaa1fad0] GtkScrollbar	height for width: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: [0x558beaa1fcd0] GtkScrollbar	width for height: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: Symbolic icon /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg is not in an icon theme directory
Gtk-Message: [0x558beaa1fad0] GtkScrollbar	height for width: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: [0x558beaa1fcd0] GtkScrollbar	width for height: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: Symbolic icon /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg is not in an icon theme directory
Gtk-Message: [0x558beaa1fad0] GtkScrollbar	height for width: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: [0x558beaa1fcd0] GtkScrollbar	width for height: -1 is minimum 6 and natural: 6 (hit cache: yes)

Gtk-Message: Symbolic icon /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg is not in an icon theme directory

I note the same behavior.  Drag a top level window (actually any widget) into the center panel and then click on "Signals"  Ram immediately starts to be consumed until system crashes.  I compiled glade-3.19.0 from scratch (./configure, make, make install) on Ubuntu 16.04.

I've got the same bug on Linux Mint 18.1, glade 3.18.3.

I can confirm CPU hogging (100% of single core) in Glade 3.20 on Windows 8.1.

To reproduce, open this sample .ui project: https://paste.ee/p/Kelea
In my experience, you don't have to click or do anything, it just starts maxing out CPU right after file is opened. If you want to investigate it better drop me an email.

In my case, only CPU is hogged, RAM stays at 100 MB which I can describe as reasonable amount.

Unfortunately I do not have glade 3.20 on my linux machine and trying to open libpvig's file with glade 3.19 crashes glade completely.

But I reiterate my experience.  Glade 3.19 on ubuntu 16.04 acts normally until I place a widget into the center panel and then click the "Signals" tab.  At that point the CPU usage goes to about 74% and RAM used by glade steadily increases until the machine crashes (about an hour on my machine).  If I click another tab (General or Common), the memory use increase stops and the CPU usage drops back to normal (1%).  So (IMHO) lipvig's case seems to be different.

I have spent some time trying to debug the problem but have had no luck.  If anyone has a suggestion, please speak up.  Even a suggestion as to where to place a break point would be welcome.

I have made some progress on debugging this on my system.  Using the glade-3.19.0 distribution package, go to the directory gladeui.  in the file glade-signal-editor.c there is a function, glade_signal_editor_init(), with several calls to gtk_tree_view_column_set_cell_data_func(). These set up callback functions that (I believe) are used to format the appearance of the columns in the signal treeview that appears on clicking the "Signals" tab. These callback functions all have names like glade_signal_editor_xxxx_cell_data_func() where xxxx is the name of a column in the treeview.

When a widget is placed in the center panel and the "Signals" tab is clicked, these callback functions are being called in an infinite loop.  This can be observed by placing a print statement in any of the functions. It is during this loop that the program starts using near 100% CPU and to slowly consume RAM until the system crashes.  I am not yet sure what is triggering this loop.  I assume that it should have been executed only once, but am unsure if this was the programmers intent or not?  Help from someone more knowledgeable about the program design would be welcome.

I have been watching this report for some time, sorry I have not "fixed" it, though.

As I suspect, from comment 13 it seems even more clear that we are looking at a GTK+ regression in treeviews, also this seems to have started happening without any code changes to Glade.

This is going to take some deep debugging, would could be most helpful would be a bisection down to the GTK+ commit which introduces this regression.

Or to rule out GTK+ being problematic, it would be interesting to use a modern GTK+ which satisfies Glade 3.19's dependency, and see how far we can back down Glade to find a version of Glade which does not behave this way (I suspect we cannot).

Tristan (comment 14):  What you suggest is a good idea... but a bit difficult.  I tried compiling glade-3.16 on Ubuntu 14.04 with gtk-3.10.  Everything works fine and no infinite loop bug in the signal editor.
But one runs into problems trying to compile glade-3.19 on that system as "configure" fails with a complaint that the gtk version is too low.
If I try to compile glade 3.16 on Ubuntu-16.04 with gtk-3.18, it compiles and installs with no obvious errors but the executable throws an error on execution and then crashes.  glade-3.18 and glade 3.19 compile on Ubuntu-16.04 with gtk-3.18 and both show the bug.
So I was not able to determine if the problem was introduced by the gtk libraries or the glade code.
I will keep poking away at it in hopes that I can figure out where the problem lies.

jim...

(In reply to lipvig from comment #11)

I want to provide an update on my issue. I'm not sure it's related but it might be.
Environment: Windows 8.1, Glade 3.20.0 64 bit.


Issue #1

1. Open Glade, create new empty project.
2. Add empty Window and inside it place a Button.
3. Everything works fine.
4. Minimize Glade window, CPU jumps to 100% of single thread.
5. Restore Glade window, CPU returns to normal.

Issue #2

1. Open Glade, create new empty project.
2. Add empty Window and inside it place a ToggleButton (instead of regular Button).
3. Everything works fine.
4. In Properties section, make the ToggleButton "Active" (tick the checkbox). CPU jumps to 100% of single thread (even when Glade window is maximized - when minimized it goes 100% no matter what is value of "Active" property).
5. Untick the "Active" checkbox. CPU returns to normal.

I'm not sure how my issues relate to Signal tab, but there is clearly big problem somewhere. I hope it might help to reproduce the problem.

Lipvig comment #16:
Interesting.  When I try your instructions with glade-3.19 on ubuntu 16.04 with gtk-3.18, I cannot reproduce your observations.  Maybe it is something to do with glade-3.20 or the Windows environment.
It is interesting though that if I drag a ToggleButton to the project center pane and then click the Signal tab... I see the CPU use jump but there is NO steady consumption of RAM as there is if the center panel contains a plain window or a plain button.  Not sure what that means.
It is strange though that the jump in CPU use occurs like this at various places in the glade program.  It is hard to believe that they not related.

(In reply to Jim Charlton from comment #15)
> Tristan (comment 14):  What you suggest is a good idea... but a bit
> difficult. 

Hi,

The only way to really bisect this is to build gtk+ and glade from git.

First i would start with getting the latest gtk+3 and latest glade master sources and build that and try to reproduce.

Next i would back down gtk+ to the version which was current at the time glade 3.19 was released, this should be the lower bound dependency indicated in glade's configure.in (but its possible that the lower bound dependency is imperfect, there may be some important gtk+ bugfixes following in a micro point release)

If glade master depends on newer gtk+ since 3.19, better use glade 3.19 (but I doubt this)

With this build, this bug should not be present.

After this you start with a bisection of gtk+ commits, rebuilding gtk+ for each commit that you try and launching glade against that build each time to reproduce, eventually finding the precise code change in gtk+ which introduced the behaviour.

One "gotcha" to be wary of is library sonames, you will want to delete from your testing install prefix, any gtk+ library .so and .la files between each build (or else glade will always link to the latest shared library installed at runtime, which might not be the same version you are currently testing)

Bisecting git commits is a tedious process but pretty much guaranteed to find the commit which introduces a bug.

I thought that I might follow up on Tristan's suggestion.  But before doing anything else, I created a Ubuntu-16.10 system with gtk-3.20 installed.  I then downloaded the latest sources for glade-3.20 and compiled.  There were a couple of non-critical problems.  The dev-help did not install and the path for the load libraries at /usr/local/lib was not specified in the Makefile.  Nevertheless, I could run the program with 'LD_LIBRARYPATH="/usr/local/lib" glade'.  And. lo and behold, there was no infinite loop nor was there memory leakage when clicking the "Signals" tab.  I could not get it to jump in CPU usage by following the description in comment #16.  While I did not really "smoke test" it... I could not find any problems.

I also downloaded the glade-3.19 sources and compiled them against the gtk-3.20 libs.  Again, there were no infinite loops etc.

I installed glade-3.20 with apt-get install glade (gives glade-3.20).  Again... no problems.

So it looks like the newer version of gtk-3 (3.20) has solved the problem. I am not really willing to spend more time chasing down the problem in glade-3.18 and 3.19 compiled against gtk-3.18.

Cheers...   jim...

Hi,

I've compiled glade-3.20 (commit 5221f9a792cbe27e9844200f8e465b95a56b7c20) against gtk-3.22.15-1 on my ArchLinux machine and the problem persistis.

I haven't compiled past that commit because it requires the Glib >= 2.53.2 version and for now I've only Glib 2.52 installed. I'll the latest revision with Glib 2.53.

Thanks
Augusto Fraga Giachero.

Nope, this bug still happening.
(Glade 3.20 commit 4fb7a84fd7408e94ec99088728f5e30bbefea753, Glib 2.53.2 commit 646041bc288c8405ce50d67910eadedf6d68e1f0, Gtk 3.22.15-1 from the ArchLinux repository).

Thanks,
Augusto Fraga Giachero.

Another things I've observed:

* When running on X11, the xorg process uses 100% CPU and the input becomes slugish for all apps, running it on Wayland the glade process uses 100% CPU but the input stays very responsive;
* The memory leak still exists, but it happens slowly.

Thanks,
Augusto Fraga Giachero.

This is very frustrating and have been like this for years. I'm om Fedora 25 with Glade 3.20.0 and the bug is still here.

Hi, here's my observations regarding Glade high CPU usage.

1st, it doesn't happen while Glade is empty. I need to add widgets to see things getting fishy.

2nd, not every widget create the bug. I didn't tried them all, but one simple widget that triggers the bug is GtkButton.

3rd, it doesn't happen while Glade has focus. Let's say I have two applications opened, Glade and a terminal. Both are visible on the screen. If Glade is the active window, no problem. As long as Glade is not the active window anymore, I see the Xorg process taking more and more CPU until it reaches 100%.

4th, the rise in CPU usage is not instantaneous. If I just have a simple GtkButton in Glade, it may take up to 10 seconds before Xorg reaches 100% CPU usage.

5th, if I switch workspace (therefore Glade is not on the current workspace), Xorg CPU usage goes back to 0%.

Just tried more widgets to try to see which ones trigger the bug.

OK widgets
----------

GtkWidget
  GtkContainer
    GtkBin
      GtkWindow
      GtkActionBar
      GtkFrame
      GtkPopover
        GtkPopoverMenu
      GtkRevealer
    GtkBox
    GtkPaned
  GtkLabel
  GtkSwitch

KO widgets
----------

GtkWidget
  GtkContainer
    GtkBin
      GtkComboBox
      GtkButton

BTW, my setup is Debian stretch, Glade 3.20.

The problem is when you have a GtkButton in Glade. When you change away from Glade the problem occurs.

Glade is trying to change the background color on the button constantly and causing the CPU load.

(If you have a GtkButton in a "Tab" (other ui file) in Glade, that is not active, it is not happening.)

I think I fixed it.

clone: https://arnaud-preevio@gitlab.com/arnaud-preevio/glade.git
branch: art/glade-3-20/xorg-100-percent

Give it a try :)

The fix seems to work. Thanks.

I made a patch against 3.20.0 on Fedora 25.

(In reply to elboulangero from comment #27)
> I think I fixed it.
> 
> clone: https://arnaud-preevio@gitlab.com/arnaud-preevio/glade.git
> branch: art/glade-3-20/xorg-100-percent
> 
> Give it a try :)

Awesome !

Thanks, the patch looks safe to me whether it fixes the issue for everyone else or not, applied this to master.

This bug has been an everlasting headache that I just did not have time to go and actually work on :)

I'll close this now with your patch to master and fingers crossed this will be done with.

Cheers !

(In reply to Tristan Van Berkom from comment #29)
> Thanks, the patch looks safe to me whether it fixes the issue for everyone
> else or not, applied this to master.
> 

I don’t see anything in git?

Ah, sorry, I applied and tested locally and looks like I failed to push, it's now upstream in Glade master.

Thanks for the nudge :)

*** Bug 776993 has been marked as a duplicate of this bug. ***

*** Bug 789059 has been marked as a duplicate of this bug. ***

*** Bug 775724 has been marked as a duplicate of this bug. ***

*** Bug 792283 has been marked as a duplicate of this bug. ***