All keyboard input fails: "IBUS-WARNING **: Events queue growing too big"
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | ibus (Ubuntu) |
Undecided
|
Unassigned | ||
Bug Description
Mouse input (eg selecting cells, opening "File/Edit/View" menus, right click context menu) all works fine, but all attempts to use the keyboard (entering content to cells, moving between cells, pasting content into cells) silently fails, with an error message printed to console of
(soffice:22108): IBUS-WARNING **: Events queue growing too big, will start to drop.
about 3 times for every keystroke
Ubuntu 15.04
libreoffice-calc:
Installed: 1:4.4.0-1ubuntu1
Candidate: 1:4.4.0-1ubuntu1
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: libreoffice-calc 1:4.4.0-1ubuntu1
ProcVersionSign
Uname: Linux 3.18.0-13-generic x86_64
ApportVersion: 2.16.1-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Thu Feb 12 20:28:05 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-07-09 (218 days ago)
InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 (20140708)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)
| themusicgod1 (themusicgod1) wrote : | #1 |
| themusicgod1 (themusicgod1) wrote : | #2 |
| themusicgod1 (themusicgod1) wrote : | #3 |
libc6:
Installed: 2.19-15ubuntu1
Candidate: 2.19-15ubuntu1
libxml2:
Installed: 2.9.2+dfsg1-3
Candidate: 2.9.2+dfsg1-3
zlib1g:
Installed: 1:1.2.8.
Candidate: 1:1.2.8.
gnumeric:
Installed: 1.12.18-1
Candidate: 1.12.18-1
| themusicgod1 (themusicgod1) wrote : | #4 |
export GTK_IM_MODULE=xim
executed before gnumeric/
| themusicgod1 (themusicgod1) wrote : | #5 |
ibus:
Installed: 1.5.9-1ubuntu2
Candidate: 1.5.9-1ubuntu2
| themusicgod1 (themusicgod1) wrote : | #6 |
($GTK_IM_MODULE is normally defined as "ibus").
| themusicgod1 (themusicgod1) wrote : | #7 |
odd chromium-browser does the exact same thing.
chromium-browser:
Installed: 40.0.2214.
Candidate: 40.0.2214.
| themusicgod1 (themusicgod1) wrote : | #8 |
empathy:
Installed: 3.12.7-1ubuntu2
Candidate: 3.12.7-1ubuntu2
Empathy appears also to be affected: actually seems worse than the others: the others work 100% when GTK_IM_MODULE is set as per above but empathy only works in the main window (chat windows still do not allow typing)
| themusicgod1 (themusicgod1) wrote : | #9 |
Also affects easytag.
easytag:
Installed: 2.2.4-1ubuntu1
Candidate: 2.2.4-1ubuntu1
I'm also noticing there might be a few keypresses that do not invoke this error, almost as if there's a buffer that gets full and then starts warning out.
| themusicgod1 (themusicgod1) wrote : | #10 |
Interestingly with easytag, navigation between different tracks on the left side is *not* affected, only text entry into the ID3 tags themselves is.
| themusicgod1 (themusicgod1) wrote : | #11 |
After closing and reopening arora (Web browser) ...ibus-daemon seems to be using 100% CPU. gdb suggests that at least part of that 100% cpu use occurs at
thread 1:
#0 0x00007f927f8c586c in g_slice_alloc (magazine_
#1 0x00007f927f8c586c in g_slice_alloc (tmem=<optimized out>, ix=0) at /build/
#2 0x00007f927f8c586c in g_slice_alloc (mem_size=
Python Exception <class 'TypeError'> iter() returned non-iterator of type '_iterator':
#3 0x00007f927f8c68a6 in g_slist_prepend (list=0x0, data=0x1cfb950) at /build/
#4 0x00007f927f8a77a0 in g_source_
#5 0x00007f927fe35af0 in g_socket_
at /build/
#6 0x00007f927fe35af0 in g_socket_
at /build/
#7 0x00007f927fe3da54 in add_sources (listener=
#8 0x00007f927fe3e535 in g_socket_
#9 0x00007f927fe3e665 in g_socket_
#10 0x00007f927fe42509 in do_accept (service=
#11 0x00007f927fe42635 in g_socket_
at /build/
#12 0x00007f927fe43aab in g_task_return_now (task=0xd66c30 [GTask]) at /build/
#13 0x00007f927fe44126 in g_task_return (task=0xd66c30 [GTask], type=<optimized out>) at /build/
#14 0x00007f927fe3dbbc in accept_ready (accept_
#15 0x00007f927fe34661 in socket_
| themusicgod1 (themusicgod1) wrote : | #12 |
(also: arora never did open)
| themusicgod1 (themusicgod1) wrote : | #13 |
libglib2.0-0:
Installed: 2.43.3-1
Candidate: 2.43.3-1
Python Exception <class 'TypeError'> iter() returned non-iterator of type '_iterator':
in the above stack trace looks particularly notable.
walking around in the function itself reveals an attempt to log an error: "fail: Error accepting connection: Too many open files". Where is this limit set?
(gdb) bt
#0 0x00007f927f0a0c8f in _int_malloc (av=0x7f927f3de760 <main_arena>, bytes=4) at malloc.c:3352
#1 0x00007f927f0a2f90 in __GI___libc_malloc (bytes=4) at malloc.c:2891
#2 0x00007f927f8aeaee in g_realloc (mem=<optimized out>, n_bytes=4) at /build/
#3 0x00007f927f8c99f7 in g_string_
#4 0x00007f927f8c9a42 in g_string_sized_new (dfl_size=
#5 0x00007f927f8ca034 in g_string_new (init=init@
#6 0x00007f927f8af87c in g_log_default_
#7 0x00007f927f8aff61 in g_logv (log_domain=
at /build/
#8 0x00007f927f8b01cf in g_log (log_domain=
at /build/
#9 0x00007f927fe42683 in g_socket_
at /build/
#10 0x00007f927fe43aab in g_task_return_now (task=0xd66d00 [GTask]) at /build/
#11 0x00007f927fe44126 in g_task_return (task=0xd66d00 [GTask], type=<optimized out>) at /build/
#12 0x00007f927fe3dbbc in accept_ready (accept_
#13 0x00007f927fe34661 in socket_
#14 0x00007f927f8a8ddd in g_main_
#15 0x00007f927f8a8ddd in g_main_
#16 0x00007f927f8a91b0 in g_main_
#17 0x00007f927f8a94d2 in g_main_loop_run (loop=0xd657d0) at /build/
| themusicgod1 (themusicgod1) wrote : | #14 |
Is it possible that the attempt to log this error message tries to open a file, and fails because ...wait for it, there's no more open files allowed for the ibus/glib2 using process? (given a default ulimit -n of 1024 for this process?). And that all you need to do is to force ibus to use 1024 files at once to trigger this? Just a thought.
| themusicgod1 (themusicgod1) wrote : | #15 |
OK here's what I think happened, and why I think it has happened.
Every morning I run an emacs macro
(fset 'traverse-
(format "(shell-command \"%s \C-e & sleep 1;\")\C-
that causes about 25-100 calls to web-browser(in this case arora). So long as Arora stays open, it does *not* release its file descriptors in the ibus process. You can confirm this by running emacs with a text file full of 100 URLs, opening arora(it has to be open already, otherwise it will only open one tab)
Esc-100 M-x traverse-
This will open up about 100 files in the proc fdinfo directory for ibus-daemon reachable by
cd /proc/`ps -ea | grep ibus-dae | awk -F' ' '{print $1}'`/fdinfo
as counted by
ls | wc -w
This is true even after you've closed the tabs that were opened in this fashion and in fact even after you've closed arora and emacs!
| themusicgod1 (themusicgod1) wrote : | #16 |
Just confirmed it gets to 1024 and these symptoms start happening. It is reproducible from a working system if you follow the above steps, and then open libreoffice-calc and then attempt to start typing with the keyboard.
| themusicgod1 (themusicgod1) wrote : | #17 |
Apparently you don't have to invoke Arora from within emacs to trigger this: even just invoking it on the commandline will suffice.
arora &
(wait till it opens)
here's the trigger:
for x in `seq 1 1024` ; do arora www.purple.
arora *does* use more fds chromium-browser *does not*.
| themusicgod1 (themusicgod1) wrote : | #18 |
Firefox leaks fds but at a slower rate than arora: firefox leaks one 1 fd per session, whereas arora leaks 1 per tab. This makes it a bug for firefox (though a minor one in comparison).
firefox:
Installed: 34.0+build2-
Candidate: 34.0+build2-
| James Cowgill (jcowgill) wrote : | #19 |
Is the bug fixed if you temporarily remove ibus? It's much more likely that this is just a bug in ibus than a bug affecting this many different packages.
| themusicgod1 (themusicgod1) wrote : | #20 |
While I try to replicate without ibus(doesn't look like it's replicating without it), really there's 3 things going on here
1) ibus process fds are being used: you could see this as an ibus issue (though that wasn't certain until #17)
2) firefox and arora cause the creation of fds within the ibus process which are never cleaned up : I guess you could view that as an ibus issue, but whether it's an ibus issue or arora/firefox issue isn't clear to me
3) chromium-browser, libreoffice, empathy, easytag and gnumeric: silently failed on ibus failure(though in some cases there was a warning warning that something *could*) happen.
| no longer affects: | libreoffice (Ubuntu) |
| no longer affects: | arora (Ubuntu) |
| no longer affects: | chromium-browser (Ubuntu) |
| no longer affects: | easytag (Ubuntu) |
| no longer affects: | empathy (Ubuntu) |
| no longer affects: | firefox (Ubuntu) |
| no longer affects: | gnumeric (Ubuntu) |
| Launchpad Janitor (janitor) wrote : | #21 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in ibus (Ubuntu): | |
| status: | New → Confirmed |
| Matteo Dell'Amico (della) wrote : | #22 |
I'm seeing the same behavior on 16.04's evince.
Exact same bug on gnumeric.