Home / ubuntu / Questions / 1053182
Accepted
Patrick Trentin
Asked: 2018-07-09 00:27:07 +0800 CST

Selecting a number does not always return a Chinese character with ibus pinyin

  • 772

I use Intelligent Pinyin Keyboard1 with ibus in Ubuntu to input Chinese characters into my document.

The input-method is designed in such a way that one types the pinyin associated with a character, and then one can select it from a list of characters using numbers 0-9 on the keyboard.

Example:

enter image description here

Problem: in the last week, it sometimes happens that when I press a number from 0-9 the input-method does not yield a Chinese character but the digit I pressed instead. Moreover, any further keyboard input is not interpreted as an input for ibus, and merely written as-is on screen until I manually switch input-mode to pinyin again.

What I tried, in order:

  • reboot
  • remove the input method configuration, and add again
  • reinstall ibus-pinyin

None of these seemed to help.

Q: Does anyone know how to solve this problem?

As a side note, there seems to be a *ibus-engine-libpinyin.*.crash file inside /var/crash that could be related to this problem. However, I am not sure how can I trace this bug-report online and see if it has already a solution online.

edit: my current workaround is to use fcitx instead of ibus .. though this doesn't really solve the problem in the software.

1 Intelligent Pinyin Keyboard can be installed by the invocation of the sudo apt-get install ibus-libpinyin and can be located in All Setting-->Text Entry-->Input sources to use-->+ as Chinese (Intelligent Pinyin) (Ibus).

keyboard input-method ibus chinese pinyin

2 Answers

  1. Best Answer

    TL;DR: rm ~/.cache/ibus/libpinyin/*

    Long answer:

    I have similar problem except my problem is not able to return any Chinese character in next column >.

    The first thing I do is run watch -n 3 -d 'ps auxww|tac' to compare what's the difference between the output when success(first column) and failure(next column) occur.

    I quickly noticed that /usr/lib/ibus/ibus-engine-libpinyin --ibus still running on success but disappear on failure.

    enter image description here

    That means /usr/lib/ibus/ibus-engine-libpinyin --ibus process crash when select character in next column.

    Since the previous process is gone, while Super+Space to toggle new libpinyin process, select the first column, then run ps auxww in another terminal to know the latest pid is 6798, run sudo strace -ff -vvv -p 6798 -s 1000000 to understand the process:

    [pid  6798] lseek(14, 12288, SEEK_SET)  = 12288
[pid  6798] read(14, "", 4096)          = 0
[pid  6798] write(2, "ibus-engine-libpinyin: ../src/lookup/phonetic_lookup.h:901: bool pinyin::PhoneticLookup<nbest>::train_result3(const pinyin::PhoneticKeyMatrix*, const pinyin::ForwardPhoneticConstraints*, MatchResult) [with int nbest = 3; MatchResult = _GArray*; GArray = _GArray]: Assertion `m_user_bigram->store(last_token, user)' failed.\n", 323) = 323
[pid  6798] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f59a80e2000
[pid  6798] rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
[pid  6798] rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
[pid  6798] getpid()                    = 6798
[pid  6798] gettid()                    = 6798
[pid  6798] tgkill(6798, 6798, SIGABRT) = 0
[pid  6798] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  6798] --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=6798, si_uid=1000} ---
[pid  6800] <... poll resumed> <unfinished ...>) = ?
[pid  6799] <... restart_syscall resumed>) = ?
[pid  6800] +++ killed by SIGABRT (core dumped) +++
[pid  6799] +++ killed by SIGABRT (core dumped) +++
+++ killed by SIGABRT (core dumped) +++

    The strace output stopped after select character in next column. Now I know it's the core dumped. Alternative way is debug with tail -f /var/log/syslog to know it's systemd-coredump.

    So I run coredumpctl list to know the coredump related pid is 6798:

    Sun 2018-10-28 06:18:31 +08    6798  1000  1000   6 present   /usr/lib/ibus/ibus-engine-libpinyin

    I run coredumpctl dump 6798 --output alamak to save coredump into alamak file, then run gdb -q /usr/lib/ibus/ibus-engine-libpinyin alamak(the executable path can get from ps auxww or coredumpctl list) to examine the coredump file:

    xb@dnxb:~$ gdb -q /usr/lib/ibus/ibus-engine-libpinyin alamak
expansion:  History expansion on command input is on.
filename:  The filename in which to record the command history is "/home/xiaobai/.gdb_history".
remove-duplicates:  The number of history entries to look back at for duplicates is 0.
save:  Saving of the history record on exit is on.
size:  The size of the command history is 10000000.
Reading symbols from /usr/lib/ibus/ibus-engine-libpinyin...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 6798]
[New LWP 6800]
[New LWP 6799]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/ibus/ibus-engine-libpinyin --ibus'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f59a80971c0 (LWP 6798))]

    Try thread apply all bt full and Enter to navigate next page, I can see some interesting keyword which is the same with the previous strace's write() output:

    (gdb) thread apply all bt full

Thread 3 (Thread 0x7f59a36a9700 (LWP 6799)):
...
#1  0x00007f59a67cd801 in __GI_abort () at abort.c:79
        save_stage = 1
        act = 
          {__sigaction_handler = {sa_handler = 0x555b8ce58800, sa_sigaction = 0x555b8ce58800}, sa_mask = {__val = {0, 18446744073709551600, 0, 0, 0, 140733365772904, 0, 140733365772736, 140023023567312, 21474836480, 140023023552472, 0, 2476426370025201152, 140023023537428, 0, 140023023552472}}, sa_flags = -1488188568, sa_restorer = 0x7f59a74c0c00}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f59a67bd39a in __assert_fail_base (fmt=0x7f59a69447d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f59a74c0c00 "m_user_bigram->store(last_token, user)", file=file@entry=0x7f59a74c0b68 "../src/lookup/phonetic_lookup.h", line=line@entry=901, function=function@entry=0x7f59a74c14e0 "bool pinyin::PhoneticLookup<nbest>::train_result3(const pinyin::PhoneticKeyMatrix*, const pinyin::ForwardPhoneticConstraints*, MatchResult) [with int nbest = 3; MatchResult = _GArray*; GArray = _GArra"...) at assert.c:92
        str = 0x555b8ce58800 ""
        total = 4096
#3  0x00007f59a67bd412 in __GI___assert_fail (assertion=0x7f59a74c0c00 "m_user_bigram->store(last_token, user)", file=0x7f59a74c0b68 "../src/lookup/phonetic_lookup.h", line=901, function=0x7f59a74c14e0 "bool pinyin::PhoneticLookup<nbest>::train_result3(const pinyin::PhoneticKeyMatrix*, const pinyin::ForwardPhoneticConstraints*, MatchResult) [with int nbest = 3; MatchResult = _GArray*; GArray = _GArra"...) at assert.c:101
#4  0x00007f59a7476a71 in pinyin_train () at /usr/lib/x86_64-linux-gnu/libpinyin.so.13
#5  0x0000555b8c7e5689 in  ()

    Now the main keyword which causes the coredump has been confirmed, google const pinyin::PhoneticKeyMatrix*, const pinyin::ForwardPhoneticConstraints*, will found this bug report thread:

    I ran libpinyin in the terminal and got the following error message:

    debian-user:~$ /usr/lib/ibus/ibus-engine-libpinyin --ibus ibus-engine-libpinyin: ../src/lookup/phonetic_lookup.h:901: bool pinyin::PhoneticLookup::train_result3(const pinyin::PhoneticKeyMatrix*, const pinyin::ForwardPhoneticConstraints*, MatchResult) [with int nbest = 3; MatchResult = _GArray*; GArray = _GArray]: Assertion `m_user_bigram->store(last_token, user)' failed. Aborted

    So this error is related to the user data. When you select a phrase other than the first one, libpinyin will try to store it in your home folder. If it doesn't work it will fail and exit.

    You may want to check the contents in ~/.cache/ibus/libpinyin/ . I simply deleted all files in this folder and kill ibus-engine-libpinyin process to restart it. They things come back to normal again. I think the problem you have is likely to be the same as mine. If not please provide error messages when you run ibus-engine-libpinyin in terminal

    ...

    I followed your instruction and deleted the ~./cache/ibus/libpinyin folder. The problem solved.

    That's it, run rm ~/.cache/ibus/libpinyin/*, and it fixed the problem.

    • 9

  2. 1.

    Moreover, any further keyboard input is not interpreted as an input for ibus, and merely written as-is on screen until I manually switch input-mode to pinyin again.

    In the SunPinyin (with the ibus input) you can set the initial state of an output for English/Chinese. It does not work on IBus Pinyin 1.5.0.

    2. At least as a stopgap until the crash is repaired, you can try to use Google Pinyin, WubiPinyin, SunPinyin or Pinyin under fcitx, which is able to manage the romanized input better.

    sudo apt install fcitx fcitx-googlepinyin fcitx-table-wbpy fcitx-pinyin fcitx-sunpinyin

    You need to change the input method for the fcitx in the System Settings --> Language Support and reboot the system (in my case to log out/log in is enough). Tray icon will show keyboard (fcitx) in place of En / Ru / Pl button (ibus).

    Then look for Google Pinyin, WubiPinyin, SunPinyin or Pinyin in All Setting --> Text Entry --> Input sources to use --> +, typing Chinese to narrow the list.

    3. (Temporary facilitation) By pressing Shift you can change the input manually as well as punctuation etc. Check: All Settings --> Text Entry --> Input source --> Preferences --> Shortcuts to assign a proper shortcut.

    • 1