Bug 1100974 - [abrt] ibus-mozc: std::__throw_out_of_range(): ibus-engine-mozc killed by SIGABRT [NEEDINFO]
Summary: [abrt] ibus-mozc: std::__throw_out_of_range(): ibus-engine-mozc killed by SIG...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mozc
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:0f585d104b03d96ebe4b2067e03...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-24 18:18 UTC by LovelyTivoli
Modified: 2014-07-09 02:30 UTC (History)
6 users (show)

Fixed In Version: mozc-1.15.1814.102-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-09 02:29:10 UTC
yukawa: needinfo? (bug)


Attachments (Terms of Use)
File: backtrace (37.55 KB, text/plain)
2014-05-24 18:18 UTC, LovelyTivoli
no flags Details
File: cgroup (172 bytes, text/plain)
2014-05-24 18:18 UTC, LovelyTivoli
no flags Details
File: core_backtrace (15.60 KB, text/plain)
2014-05-24 18:18 UTC, LovelyTivoli
no flags Details
File: dso_list (2.35 KB, text/plain)
2014-05-24 18:19 UTC, LovelyTivoli
no flags Details
File: environ (3.56 KB, text/plain)
2014-05-24 18:19 UTC, LovelyTivoli
no flags Details
File: limits (1.29 KB, text/plain)
2014-05-24 18:19 UTC, LovelyTivoli
no flags Details
File: maps (12.38 KB, text/plain)
2014-05-24 18:19 UTC, LovelyTivoli
no flags Details
File: open_fds (662 bytes, text/plain)
2014-05-24 18:19 UTC, LovelyTivoli
no flags Details
File: proc_pid_status (949 bytes, text/plain)
2014-05-24 18:19 UTC, LovelyTivoli
no flags Details
File: var_log_messages (207 bytes, text/plain)
2014-05-24 18:19 UTC, LovelyTivoli
no flags Details

Description LovelyTivoli 2014-05-24 18:18:48 UTC
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

Comment 1 LovelyTivoli 2014-05-24 18:18:55 UTC
Created attachment 898952 [details]
File: backtrace

Comment 2 LovelyTivoli 2014-05-24 18:18:57 UTC
Created attachment 898953 [details]
File: cgroup

Comment 3 LovelyTivoli 2014-05-24 18:18:59 UTC
Created attachment 898954 [details]
File: core_backtrace

Comment 4 LovelyTivoli 2014-05-24 18:19:01 UTC
Created attachment 898955 [details]
File: dso_list

Comment 5 LovelyTivoli 2014-05-24 18:19:03 UTC
Created attachment 898956 [details]
File: environ

Comment 6 LovelyTivoli 2014-05-24 18:19:05 UTC
Created attachment 898957 [details]
File: limits

Comment 7 LovelyTivoli 2014-05-24 18:19:07 UTC
Created attachment 898958 [details]
File: maps

Comment 8 LovelyTivoli 2014-05-24 18:19:09 UTC
Created attachment 898959 [details]
File: open_fds

Comment 9 LovelyTivoli 2014-05-24 18:19:11 UTC
Created attachment 898960 [details]
File: proc_pid_status

Comment 10 LovelyTivoli 2014-05-24 18:19:12 UTC
Created attachment 898961 [details]
File: var_log_messages

Comment 11 Yohei Yukawa 2014-06-01 16:49:30 UTC
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 [details] 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.cc?r=185#233
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#gobject-The-Base-Object-Type.description
  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 [details]) 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.

Comment 12 Yohei Yukawa 2014-06-21 18:03:04 UTC
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!

Comment 13 Akira TAGOH 2014-06-26 03:17:16 UTC
(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?

Comment 14 Yohei Yukawa 2014-06-26 05:54:16 UTC
> 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_template.txt

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-download-service.html

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.

Comment 15 Akira TAGOH 2014-06-27 03:26:23 UTC
Thanks. building new version then.

Comment 16 Fedora Update System 2014-06-27 03:29:58 UTC
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

Comment 17 Fedora Update System 2014-06-27 05:40:44 UTC
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

Comment 18 Fedora Update System 2014-06-27 21:50:21 UTC
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-1.fc20
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2014-07-09 02:29:10 UTC
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.

Comment 20 Fedora Update System 2014-07-09 02:30:57 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.