Terminator locks up with 100% CPU, when trying to split panes too many times

[Dominic Hopf]

Terminator crashes, when it gets split into too many windows, e.g. when pressing Ctrl+Shift+O a few times. There are some Fedora users also affected from this bug. For backtraces see [1] and concerned bugs.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=595840

[Jorge Pereira (jpereiran)]

I Have the same problem when try using the terminator with many tabs.

# out of dmesg
[89095.853940] /usr/bin/termin[30107]: segfault at 10 ip 00ff848d sp bf854200 error 4 in libgtk-x11-2.0.so.0.2000.1[f3d000+3cd000]

Below following the output of ubuntu-bug

[jpereira@miracleworld ~]$ ubuntu-bug --save=/tmp/terminator terminator
[jpereira@miracleworld ~]$ cat /tmp/terminator
ProblemType: Bug
Architecture: i386
Date: Thu Jul 29 16:46:49 2010
Dependencies:
 adduser 3.112ubuntu1
 base-files 5.0.0ubuntu20.10.04.1
 base-passwd 3.5.22
 busybox-initramfs 1:1.13.3-1ubuntu11
 coreutils 7.4-2ubuntu2
 cpio 2.10-1ubuntu2
 cpp 4:4.4.3-1ubuntu1
 cpp-4.4 4.4.3-4ubuntu5
 dbus 1.2.16-2ubuntu4
 dbus-x11 1.2.16-2ubuntu4
 debconf 1.5.28ubuntu4
 debconf-i18n 1.5.28ubuntu4
 debianutils 3.2.2
 defoma 0.11.10-4ubuntu1
 dpkg 1.15.5.6ubuntu4.1
 file 5.03-5ubuntu1
 findutils 4.4.2-1ubuntu1
 fontconfig 2.8.0-2ubuntu1
 fontconfig-config 2.8.0-2ubuntu1
 gcc-4.4-base 4.4.3-4ubuntu5
 gconf2 2.28.1-0ubuntu1
 gconf2-common 2.28.1-0ubuntu1
 ifupdown 0.6.8ubuntu29
 initramfs-tools 0.92bubuntu78
 initramfs-tools-bin 0.92bubuntu78
 initscripts 2.87dsf-4ubuntu17
 insserv 1.12.0-14
 klibc-utils 1.5.17-4ubuntu1
 libacl1 2.2.49-2
 libatk1.0-0 1.30.0-0ubuntu2.1
 libattr1 1:2.4.44-1
 libavahi-client3 0.6.25-1ubuntu6
 libavahi-common-data 0.6.25-1ubuntu6
 libavahi-common3 0.6.25-1ubuntu6
 libblkid1 2.17.2-0ubuntu1
 libbz2-1.0 1.0.5-4
 libc-bin 2.11.1-0ubuntu7.2
 libc6 2.11.1-0ubuntu7.2
 libcairo2 1.8.10-2ubuntu1
 libcomerr2 1.41.11-1ubuntu2
 libcups2 1.4.3-1ubuntu1.2
 libdatrie1 0.2.2-3
 libdb4.8 4.8.24-1ubuntu1
 libdbus-1-3 1.2.16-2ubuntu4
 libdbus-glib-1-2 0.84-1
 libdirectfb-1.2-0 1.2.8-5ubuntu2
 libdrm-intel1 2.4.18-1ubuntu3
 libdrm-nouveau1 2.4.18-1ubuntu3
 libdrm-radeon1 2.4.18-1ubuntu3
 libdrm2 2.4.18-1ubuntu3
 libexpat1 2.0.1-7ubuntu1
 libffi5 3.0.9-1
 libfontconfig1 2.8.0-2ubuntu1
 libfreetype6 2.3.11-1ubuntu2.1
 libgcc1 1:4.4.3-4ubuntu5
 libgconf2-4 2.28.1-0ubuntu1
 libgcrypt11 1.4.4-5ubuntu2
 libgdbm3 1.8.3-9
 libglib2.0-0 2.24.1-0ubuntu1
 libgmp3c2 2:4.3.2+dfsg-1ubuntu1
 libgnutls26 2.8.5-2
 libgpg-error0 1.6-1ubuntu2
 libgssapi-krb5-2 1.8.1+dfsg-2ubuntu0.2
 libgtk2.0-0 2.20.1-0ubuntu2
 libgtk2.0-bin 2.20.1-0ubuntu2
 libgtk2.0-common 2.20.1-0ubuntu2
 libidl0 0.8.13-1
 libjasper1 1.900.1-7
 libjpeg62 6b-15ubuntu1
 libk5crypto3 1.8.1+dfsg-2ubuntu0.2
 libkeyutils1 1.2-12
 libklibc 1.5.17-4ubuntu1
 libkrb5-3 1.8.1+dfsg-2ubuntu0.2
 libkrb5support0 1.8.1+dfsg-2ubuntu0.2
 libldap-2.4-2 2.4.21-0ubuntu5
 liblocale-gettext-perl 1.05-6
 libmagic1 5.03-5ubuntu1
 libmpfr1ldbl 2.4.2-3ubuntu1
 libncurses5 5.7+20090803-2ubuntu3
 libncursesw5 5.7+20090803-2ubuntu3
 libnewt0.52 0.52.10-5ubuntu1
 libnih-dbus1 1.0.1-1
 libnih1 1.0.1-1
 liborbit2 1:2.14.18-0.1
 libpam-modules 1.1.1-2ubuntu5
 libpam0g 1.1.1-2ubuntu5
 libpango1.0-0 1.28.0-0ubuntu2
 libpango1.0-common 1.28.0-0ubuntu2
 libpcre3 7.8-3build1
 libpixman-1-0 0.16.4-1ubuntu2
 libplymouth2 0.8.2-2ubuntu2
 libpng12-0 1.2.42-1ubuntu2.1
 libpopt0 1.15-1
 libreadline6 6.1-1
 libsasl2-2 2.1.23.dfsg1-5ubuntu1
 libselinux1 2.0.89-4
 libsepol1 2.0.40-2
 libslang2 2.2.2-2ubuntu1
 libsqlite3-0 3.6.22-1
 libssl0.9.8 0.9.8k-7ubuntu8
 libstdc++6 4....

[Chris Jones (cmsj)]

Jorge: do you have some steps to reproduce the crash?

[Dominic Hopf (dmaphy)]

Seems I can still reproduce this issue with Terminator 0.94. Even if you did not ask me, steps to reproduce is very easy: Press Ctrl+Shift+O a few times in short time intervals.

Hope this helps to fix the issue.

Best Regards,
Dominic

[Dwaalspoor98 (dwaalspoor98)]

I have the same issue but I suspect it's not related to the number of screens. How I can reproduce this: open terminator and split windows as fast as you can. Than it crashes pretty soon! (same in 0.94 as 0.95 PPA versions) If you are unable to reproduce please tell me the details you need.

[Chris Jones (cmsj)]

I'm curious what kind of hardware people are seeing this on - I've never been able to reproduce it on my laptop, but maybe it's just not fast enough?

[Dwaalspoor98 (dwaalspoor98)]

This are the specs from my laptop, but I can also reproduce the crash in a few seconds on my Quad Core I7 running at 2.8 Ghz desktop.

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz
stepping : 10
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida tpr_shadow vnmi flexpriority
bogomips : 5586.40
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz
stepping : 10
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida tpr_shadow vnmi flexpriority
bogomips : 5586.00
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Should be fast enough I assume,

jpoppe@astray98:~$ free -m
             total used free shared buffers cached
Mem: 3951 1476 2475 0 53 584
-/+ buffers/cache: 838 3113
Swap: 5130 0 5130

jpoppe@astray98:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller ...

[Dominic Hopf (dmaphy)]

Well, I have 4G of RAM here and my CPU is a AMD Athlon(tm) Dual Core Processor 4850e with a maximum frequency of 2GHz per core. The system is indeed a bit fast, yes.

[Stephen Boddy (stephen-j-boddy)]

Can I ask those of you experiencing this to be a little more descriptive of what you mean by "crash".

Do you mean it exits with segfault? Exits with stack trace? Or locks up, and soaks up lots of CPU, i.e 100% of a core?

I'm seeing the 100% core lockup. I've so far got it down to something where two vte's seem to get into a "fight" trying to get space. It's like:
1) A says "I need P",
2) the splitter tells B "you now have Q",
3) B says "no way! I need at least R",
4) splitter tells A "Sorry, can you cope with S",
5) A says "Nope, I need P",
6) Goto 2

The key thing that seems to kick it off is dividing a space where the two vte's get <1 line of height. The strange thing is that it's not 100% reproducible in trunk. I have been working on some optimisations, and one of them makes this happen very easily. It seems like a way to set minimum height/widths, and either deny a split, or to force splitters higher up the hierarchy to give us more space. (Yes, I have also seen this trigger on vertical splitters too, but we don't typically split as small horizontally as we do vertically.)

You can add "print self, repr(allocation)" to the top of the on_vte_size_allocate method in terminatorlib/terminal.py and then try to trigger the issue. What you should see on the stdout is lots of cycling. i.e.
<Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 27, 642, 23)
<Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 63, 642, 1)
<Terminal object at 0x2702be0 (terminatorlib+terminal+Terminal at 0x2413160)> gtk.gdk.Rectangle(0, 17, 642, 23)
<Terminal object at 0x2702be0 (terminatorlib+terminal+Terminal at 0x2413160)> gtk.gdk.Rectangle(0, 17, 642, 1)
<Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 27, 642, 23)
<Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 63, 642, 1)
<Terminal object at 0x2702be0 (terminatorlib+terminal+Terminal at 0x2413160)> gtk.gdk.Rectangle(0, 17, 642, 23)
<Terminal object at 0x2702be0 (terminatorlib+terminal+Terminal at 0x2413160)> gtk.gdk.Rectangle(0, 17, 642, 1)

[Dwaalspoor98 (dwaalspoor98)]

Hi Stephen,

I can't live anymore without Terminator, so of course I want to be more detailed! ;)

Attached is my configuration which I use on all my computers/laptops and the output of Terminator with the added print statement.

The freeze indeed uses 100% CPU, no exceptions are thrown or whatever, it just locks up until I kill it.

It's indeed getting a small area when it crashes but to my feeling still more than one line left, I have a 30 inch monitor and there seems to be some space left.

Since I can reproduce the issue in less than 2 seconds it's no problem. I hope this information is helpful. If not tell me what to do more, I know quite some Python (not really into PyGTK) but if you want to add me more debug statements, no problem.

Eventually I could give you temporarily access to one of my boxes so you could try it by yourself.

Thanks for your time!

Greetings,

Poppe

> Date: Mon, 13 Sep 2010 17:20:02 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 593290] Re: Terminator crashes, when trying to split in too many windows
>
> Can I ask those of you experiencing this to be a little more descriptive
> of what you mean by "crash".
>
> Do you mean it exits with segfault? Exits with stack trace? Or locks up,
> and soaks up lots of CPU, i.e 100% of a core?
>
> I'm seeing the 100% core lockup. I've so far got it down to something where two vte's seem to get into a "fight" trying to get space. It's like:
> 1) A says "I need P",
> 2) the splitter tells B "you now have Q",
> 3) B says "no way! I need at least R",
> 4) splitter tells A "Sorry, can you cope with S",
> 5) A says "Nope, I need P",
> 6) Goto 2
>
> The key thing that seems to kick it off is dividing a space where the
> two vte's get <1 line of height. The strange thing is that it's not 100%
> reproducible in trunk. I have been working on some optimisations, and
> one of them makes this happen very easily. It seems like a way to set
> minimum height/widths, and either deny a split, or to force splitters
> higher up the hierarchy to give us more space. (Yes, I have also seen
> this trigger on vertical splitters too, but we don't typically split as
> small horizontally as we do vertically.)
>
> You can add "print self, repr(allocation)" to the top of the on_vte_size_allocate method in terminatorlib/terminal.py and then try to trigger the issue. What you should see on the stdout is lots of cycling. i.e.
> <Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 27, 642, 23)
> <Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 63, 642, 1)
> <Terminal object at 0x2702be0 (terminatorlib+terminal+Terminal at 0x2413160)> gtk.gdk.Rectangle(0, 17, 642, 23)
> <Terminal object at 0x2702be0 (terminatorlib+terminal+Terminal at 0x2413160)> gtk.gdk.Rectangle(0, 17, 642, 1)
> <Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 27, 642, 23)
> <Terminal object at 0x2716d70 (terminatorlib+terminal+Terminal at 0x2413700)> gtk.gdk.Rectangle(0, 63, 642, 1)
> <Terminal object at 0x2702be0 (terminatorlib+terminal+Terminal at 0x24...

[Stephen Boddy (stephen-j-boddy)]

Hi Poppe,

In your attached crashlog.tgz you can see the allocate at the end of the lines which is a rectangle of (x,y,w,h). You can see that once we get into the deadlock loop the first terminal gets a height (h) of 47, then 6. Then the second terminal gets 47, then 6. Then back to the first. I'm guessing that the value 6 is less than your font size.

I've read elsewhere of panes causing two allocate events with different values. Something funky is going on, but I haven't figured it out yet.

[Chris Jones (cmsj)]

I've been idly wondering if some locking would help. It seems like a key factor here is the speed at which splitting is happening - perhaps we need to wait until a terminal has been fully rendered before we accept a split request. I'm not 100% sure off the top of my head which gtk signal can be used for "I have finished setting up", but I wondered if it could be tied into our spawn_child(). That would depend on some guarantee from vte that fork_command() returns at a point where the terminal definitely exists and has been laid out.

[Kejope (kejope)]

I have to sleep now. I will provide more details tomorrow.

I can reproduce this freezing bug consistently and scriptedly in VirtualBox with a clean Ubuntu Lucid install. Hopefully, the ability to script it will help to find a fix. Within the vm, running the script, I get these results:
works: ./tt.sh notitlebars 3
freezes: ./tt.sh notitlebars 4
works, but with maybe 10 second delay: ./tt.sh vanilla 30

Then, ssh to the physical Lucid machine, I can only use low numbers, like 2 or 3, for each. (Details later, if wanted.)
Then, successfully run tests with high numbers, like 40 and 50, for each. Seems like the faster the machine, the less chance of this bug appearing.

Very important to not touch keyboard or click somewhere while script is running. It injects keystrokes to current window. :) Which reminds me, you will need to install xdotools, which is very small. sudo aptitude install xdotools

1. Ubuntu Karmic. python-vte 1:0.22.2-0ubuntu2.1. Terminator 0.95ppa2. Compiz and Gnome
Hardware is certainly not too slow: 4G RAM on AMD Athlon(tm) 64 X2 Dual Core Processor 5600+.
2. Ubuntu Lucid. python-vte 1:0.23.5-0ubuntu1.1. Terminator 0.93-0ubuntu1. Metacity and Gnome
Hardware is somewhere similar, but don't remember details at the moment.

In the meantime, enjoy the script. Let me know of improvements, also. :)

tt.sh:
#!/bin/bash
CREATED=2010-09-30
MODIFIED=2010-09-30
VERSION=01.000.000
LICENSE="Public Domain"
##########################################
## Use this code at your own risk! ##
## I am not responspible for any ##
## results that come from your using ##
## it! ##
##########################################

# You should definitely make a backup of ~/.config/terminator/config
# This program will erase that file.

# Ignore this terminator PID when killing later. If you want/need this functionality,
# you will have to get the appropriate pid and put it here:
IGNOREPID=

##### A few functions defined

prepconfig() {
 local what="$1"

 echo "test=$what"
 case "$what" in
  vanilla)
   # We have Titlebars.
   echo "" > ~/.config/terminator/config
   ;;

  notitlebars)
   # We disable Titlebars.
   echo "[profiles]" > ~/.config/terminator/config
   echo "[[default]]" >> ~/.config/terminator/config
   echo "show_titlebar = False" >> ~/.config/terminator/config
   ;;

  *)
   ERR="ERR:prepconfig: Invalid TEST: $what"
   return 1
   ;;
 esac
}

xdotest() {
 local what="$1"
 local count=$2
 local i

 case "$what" in
  vanilla)
   for i in $( seq 1 $count ); do
    xdotool type $i
    xdotool key ctrl+shift+o
    xdotool key alt+Up
   done
   for i in $( seq 1 $count ); do
    xdotool key ctrl+shift+w
   done
   ;;

  notitlebars)
   for i in $( seq 1 $count ); do
    xdotool type $i
    xdotool key ctrl+shift+o
    xdotool key alt+Up
   done
   for i in $( seq 1 $count ); do
    xdotool key ctrl+shift+w
   done
   ;;

  *)
   ERR="ERR:xdotest: Invalid TEST: $what"
   return 1
   ;;
 esac
}

init() {
 if [[ "$1" == "" ]] || [[ "$2" == "" ]]; then
  echo "Usage:"
  echo "tt.sh TEST COUNT"
  echo ""
  echo "Where TEST is one of these:"
  echo " vanilla, titlebars"
  echo "and COU...

[Kejope (kejope)]

I have updated my script to include, among other things, THREE automated freeze tests.
Rather than repost here (unless you prefer that I do), here are the details:
https://bugs.launchpad.net/terminator/+bug/328235/comments/23

Please let me know if this tool is actually useful to you. Thanks!

[Kejope (kejope)]

Tiny typo prevented vanilla and notitlebars tests from running. Fixed.

Inside VirtualBox, clean Ubuntu Lucid.
works: ./tt.sh vanilla 5
freezes: ./tt.sh vanilla 6
works: ./tt.sh notitlebars 3
freezes: ./tt.sh notitlebars 4
buggy alt-direction behaviour displayed: each of dirs1, dirs2, and dirs3 tests
freezes: each of freeze1, freeze2, and freeze3 tests

The automated tool includes a 'sleep 1' in between key presses. You can easily change the delay amount.
Also, if the geometry of the window is wider, then freeze1, freeze2, and freeze3 tests will not actually freeze, unless you do ctrl+shift+e more times.

[Chris Jones (cmsj)]

Kejope: so I've run all of the tt.sh tests on my laptop and none of them produce any kind of freezing or excessive CPU consumption, which is rather odd.

FWIW my laptop is a 2.4Ghz Core2Duo with an nVidia mobile chipset of some variety using the binary nVidia driver. Previously I was on a 1.4Ghz Core2Duo with an Intel X4500HD graphics chipset.

I did notice that most of the test cases that were supposed to produce crashing ended up with terminals that were very small indeed and I'm wondering if that is what's causing the problem - perhaps in some situations VTE is failing because it's being given an impossibly tiny amount of space? For a while I've been thinking we should impose a minimum size on terminals.

[Michael Lustfield (michaellustfield)]

I think it's probably from the speed at which they're generated. I can generate them quickly and keep black space in each new terminal visible by clicking very quickly into a larger area and continuing to create new terminals.

Also.. making many terminals in a space not at a very high speed only a small lag is noticed.

As for the gtk signal...
Maybe you could have a variable sitting in terminator that..
- Config changeable value
- Value set for max generating terms.
- Request to build term
- If $being_built < $max_generating
-- Term starts being generated; $being_built += 1;
-- Term built; $being_built -= 1;

Just a thought..

[Stephen Boddy (stephen-j-boddy)]

Hi Bug subscribers, this is the maintainer (Steve Boddy) of Terminator, who took over from Chris.

In case you were not aware there has been a new release 0.98 of Terminator in the last few days which has many changes, fixes and updates. We also have an ongoing GTK3 port which uses a much more up-to-date libvte.

Even with the ~50 issues closed by that release, and discounting the ~90 outstanding wishlist items, we still have an unwieldy 95 bugs. With the oldest approaching it's 6th birthday and some that haven't seen any updates in nearly 5, it is time for a purge.

My intention is to try and get this list down to a minimum, and for that I need your help.

First I'm going to work through, oldest to newest, setting bugs to Incomplete, pending confirmation that they are still an issue. If after a month there is no feedback, the issue will get closed as Invalid. Here's where you come in. I can't always reproduce, or setting up (i.e. other distros) to even test takes a long time, so I'm going to try crowdsourcing this.

1. Get the latest release. Is it still an issue? If yes, set the confirmed-0.98 tag. For bonus points follow the guide http://gnometerminator.blogspot.com/2015/09/so-you-want-to-try-terminator-gtk3.html and see if the GTK3 branch has same issue, and set the confirmed-gtk3 or notaffected-gtk3 tag.

2. Can you reproduce with an empty/default config file? You can pass "-g temp_config" to do this without affecting your existing config. If you already have Terminator running, you'll need to pass -u as well to disable the DBus.

3. If able to, can you reproduce with another user/guest account?

4. If the issue does not already have clear, precise instructions to reproduce with minimal setup/steps, add them.

5. Put as much info about what you are running.
   * Software/library versions (libvte, gtk, pango, cairo, distro, desktop environment, language)
   * Screens (single or multi)
   * Any unusual / custom packages or configs that might be interacting.

6. If possible attach the config file, unless the issue also happens with an empty one, but mention that.

7. Attach the "-d" debug output from 0.98.

Some common things that cause incidents.

* Strange sizing issues or rapidly shrinking windows - Try turning off Window geometry hints.
* Input (esp. broadcasting duplicate chars etc) problems - Try killing IBus.
* Hand editing of the config file can cause various issues - Due to misunderstanding, incorrect structure or typos.
* Some issues are actually in libvte - This is why testing GTK3 is so important.
* segfaults - Unfortunately these are dying inside the C libraries, and it is usually beyond me to fix those.

Many thanks for your assistance, and hopefully this will get us closer to a bug-free Terminator.

[Stephen Boddy (stephen-j-boddy)]

Hi, maintainer here. Terminator has moved on from gtk2 and we now have a brand-spanking new gtk3 version. Sadly we also have many ancient bugs, and it's not really practical to struggle to replicate them considering how widely the code bases have diverged.

I'm setting these older bugs to Invalid. If you wish to reactivate the bug please reproduce with at least gtk3 and release 1.90 (even better if you use head of the gtk3 branch), then set the status to New. This way we only have to focus on things that still impact users.