[Fedora-i18n-bugs] [Bug 1100974] New: [abrt] ibus-mozc: std::__throw_out_of_range(): ibus-engine-mozc killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
Bug ID: 1100974 Summary: [abrt] ibus-mozc: std::__throw_out_of_range(): ibus-engine-mozc killed by SIGABRT Product: Fedora Version: 20 Component: mozc Assignee: tagoh@redhat.com Reporter: bug@funcy.com QA Contact: extras-qa@fedoraproject.org CC: i18n-bugs@lists.fedoraproject.org, liangsuilong@gmail.com, tagoh@redhat.com, tfujiwar@redhat.com
Description of problem: 1.I edited with vim. 2.change mode which used ctrl+space. 3.Error occur.
Version-Release number of selected component: ibus-mozc-1.13.1651.102-1.fc20
Additional info: reporter: libreport-2.2.2 backtrace_rating: 4 cmdline: /usr/libexec/ibus-engine-mozc --ibus crash_function: std::__throw_out_of_range executable: /usr/libexec/ibus-engine-mozc kernel: 3.14.2-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000
Truncated backtrace: Thread no. 1 (9 frames) #6 std::__throw_out_of_range at ../../../../../libstdc++-v3/src/c++11/functexcept.cc:80 #7 _M_check at /usr/include/c++/4.8.2/bits/basic_string.h:324 #8 substr at /usr/include/c++/4.8.2/bits/basic_string.h:2208 #9 mozc::ibus::(anonymous namespace)::GetSurroundingText at unix/ibus/mozc_engine.cc:233 #10 mozc::ibus::MozcEngine::ProcessKeyEvent at unix/ibus/mozc_engine.cc:395 #11 _ibus_marshal_BOOLEAN__UINT_UINT_UINT at ibusmarshalers.c:290 #16 ibus_engine_service_method_call at ibusengine.c:864 #17 call_in_idle_cb at gdbusconnection.c:4868 #22 ibus_main at ibusshare.c:301
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
Yohei Yukawa yukawa@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bug@funcy.com, | |yukawa@google.com Flags| |needinfo?(bug@funcy.com)
--- Comment #11 from Yohei Yukawa yukawa@google.com --- Hi LovelyTivoli, I'm interested in the way how to reproduce this issue. I couldn't reproduce this issue on Fedora 20. Can you elaborate a bit more about the detailed steps to reproduce this issue?
BTW, your attachment 898952 seems to be explaining what is going on.
https://bugzilla.redhat.com/attachment.cgi?id=898952 #6 0x0000003c55cb3aa7 in std::__throw_out_of_range (__s=__s@entry=0x48f776 "basic_string::substr") at ../../../../../libstdc++-v3/src/c++11/functexcept.cc:80 No locals. #7 0x00000000004129a5 in _M_check (__s=0x48f776 "basic_string::substr", __pos=18, this=0x7fffe7c2fe70) at /usr/include/c++/4.8.2/bits/basic_string.h:324 No locals. #8 substr (__n=18446744073709551615, __pos=18, this=0x7fffe7c2fe70) at /usr/include/c++/4.8.2/bits/basic_string.h:2208 No locals. #9 mozc::ibus::(anonymous namespace)::GetSurroundingText (engine=engine@entry=0x213f2a0, selection_monitor=<optimized out>, info=info@entry=0x7fffe7c2ff40) at unix/ibus/mozc_engine.cc:233 anchor_pos = 0 surrounding_text = "/var/log/messages" cursor_pos = 18 text = 0x7f200c006580 selection_length = 18
And here is the corresponding code in Mozc. https://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/mozc_engine... bool GetSurroundingText(IBusEngine *engine, #ifdef MOZC_ENABLE_X11_SELECTION_MONITOR SelectionMonitorInterface *selection_monitor, #endif // MOZC_ENABLE_X11_SELECTION_MONITOR SurroundingTextInfo *info) { if (!(engine->client_capabilities & IBUS_CAP_SURROUNDING_TEXT)) { VLOG(1) << "Give up CONVERT_REVERSE due to client_capabilities: " << engine->client_capabilities; return false; } guint cursor_pos = 0; guint anchor_pos = 0; // DO NOT call g_object_unref against this. // http://ibus.googlecode.com/svn/docs/ibus-1.4/IBusText.html // http://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#... IBusText *text = NULL; ibus_engine_get_surrounding_text(engine, &text, &cursor_pos, &anchor_pos); const string surrounding_text(ibus_text_get_text(text));
#ifdef MOZC_ENABLE_X11_SELECTION_MONITOR if (cursor_pos == anchor_pos && selection_monitor != NULL) { const SelectionInfo &info = selection_monitor->GetSelectionInfo(); guint new_anchor_pos = 0; if (SurroundingTextUtil::GetAnchorPosFromSelection( surrounding_text, info.selected_text, cursor_pos, &new_anchor_pos)) { anchor_pos = new_anchor_pos; } } #endif // MOZC_ENABLE_X11_SELECTION_MONITOR
if (!SurroundingTextUtil::GetSafeDelta(cursor_pos, anchor_pos, &info->relative_selected_length)) { LOG(ERROR) << "Too long text selection."; return false; }
const uint32 selection_start = min(cursor_pos, anchor_pos); const uint32 selection_length = abs(info->relative_selected_length); info->preceding_text = surrounding_text.substr(0, selection_start); // <---- Crash Here Util::SubString(surrounding_text, selection_start, selection_length, &info->selection_text); info->following_text = surrounding_text.substr( selection_start + selection_length); return true; }
What I can tell from your crash log (attachment 898952) is that ibus_engine_get_surrounding_text returned the following values: - text: "/var/log/messages" - cursor_pos: 18 - anchor_pos: (probably) 0
This is problematic because cursor_pos is out of the range of the returned text "/var/log/messages", which consists of 17 characters only. I'm not sure why IBus returns this sort of invalid values but my takeaways are: a. (If my assumption is true), IBus should have had some range checking for ibus_engine_get_surrounding_text. b. (If my assumption is true), ibus-mozc should not have assumed that IBus always returns valid data.
As for b., a possible workaround is to make sure cursor_pos and anchor_pos do not point outside of surrounding_text as follows:
ibus_engine_get_surrounding_text(engine, &text, &cursor_pos, &anchor_pos); - const string surrounding_text(ibus_text_get_text(text)); + const gchar *text_ptr = ibus_text_get_text(text); + const string surrounding_text(text_ptr != nullptr ? text_ptr : ""); + cursor_pos = min(cursor_pos, surrounding_text.size()); + anchor_pos = min(anchor_pos, surrounding_text.size());
Anyway, it would be nice if reliable reproducible steps is provided so that I can test this on my local environment, or you can rebuild ibus-mozc with above change to check whether the crash disappears or not.
Thanks.
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
--- Comment #12 from Yohei Yukawa yukawa@google.com --- I believe that this particular crash should be resolved by upgrading Mozc 1.15.1813.102 and later, though I'm still unable to reproduce this issue.
See Mozc Issue 226, SVN rev.232, and rev.233 about how it is fixed. https://code.google.com/p/mozc/issues/detail?id=226 https://code.google.com/p/mozc/source/detail?r=232 https://code.google.com/p/mozc/source/detail?r=233
Thanks!
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
--- Comment #13 from Akira TAGOH tagoh@redhat.com --- (In reply to Yohei Yukawa from comment #12)
I believe that this particular crash should be resolved by upgrading Mozc 1.15.1813.102 and later, though I'm still unable to reproduce this issue.
No such releases has been made in public or at least I can't find it out in the download page though, any plans to make a new release?
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
--- Comment #14 from Yohei Yukawa yukawa@google.com ---
No such releases has been made in public or at least I can't find it out in the download page though, any plans to make a new release?
You can treat any SVN commit of Mozc as a public release as long as it updates the version code. Feel free to pick up any release you like. All of them are official public releases. https://code.google.com/p/mozc/source/list?path=/trunk/src/mozc_version_temp...
I may irregularly update the ReleaseHistory page, but the ReleaseHistory page has been maintained just for the record, especially for down integration from Google internal upstream repository to OSS Mozc public repository. Usually such down integrations are done as one giant commit where many non-trivial changes are squashed (it's unfortunate and I dislike it though). https://code.google.com/p/mozc/wiki/ReleaseHistory
If you are wondering about which version should be used, one possible approach could be to choose the latest version when you want to update the postal code dictionary, which is also supposed to be released regularly once a month by Japan Post Co., Ltd. Of course you can use any strategy that is convenient for you. It's up to you.
As for the download page, unfortunately (sorry again) the download functionality in Google code has been deprecated as announced one year ago. This is why the page is no longer updated. http://google-opensource.blogspot.jp/2013/05/a-change-to-google-code-downloa...
Currently we don't have any plan to release tarball at somewhere else. If some Linux distros heavily rely on tarball for their packaging systems, one option could be to organize a joint team across distros to generate and maintain source tarballs for their own use. This might be a reasonably convenient and flexible way for Linux distros to maintain source tarballs especially if they don't care about other platforms such as Windows, Mac, NaCl, and Android.
Hope this helps.
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #15 from Akira TAGOH tagoh@redhat.com --- Thanks. building new version then.
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
--- Comment #16 from Fedora Update System updates@fedoraproject.org --- mozc-1.15.1814.102-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mozc-1.15.1814.102-1.fc20
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
--- Comment #17 from Fedora Update System updates@fedoraproject.org --- mozc-1.15.1814.102-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mozc-1.15.1814.102-1.fc19
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #18 from Fedora Update System updates@fedoraproject.org --- Package mozc-1.15.1814.102-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mozc-1.15.1814.102-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7813/mozc-1.15.1814.102-... then log in and leave karma (feedback).
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Fixed In Version| |mozc-1.15.1814.102-1.fc19 Resolution|--- |ERRATA Last Closed| |2014-07-08 22:29:10
--- Comment #19 from Fedora Update System updates@fedoraproject.org --- mozc-1.15.1814.102-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=1100974
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|mozc-1.15.1814.102-1.fc19 |mozc-1.15.1814.102-1.fc20
--- Comment #20 from Fedora Update System updates@fedoraproject.org --- mozc-1.15.1814.102-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
i18n-bugs@lists.fedoraproject.org
-
Red Hat Bugzilla