Bug 1100974

Created attachment 898952 [details]
File: backtrace

Created attachment 898953 [details]
File: cgroup

Created attachment 898954 [details]
File: core_backtrace

Created attachment 898955 [details]
File: dso_list

Created attachment 898956 [details]
File: environ

Created attachment 898957 [details]
File: limits

Created attachment 898958 [details]
File: maps

Created attachment 898959 [details]
File: open_fds

Created attachment 898960 [details]
File: proc_pid_status

Created attachment 898961 [details]
File: var_log_messages

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.

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!

(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?

> 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.

Thanks. building new version then.

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

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

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).

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.

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.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days