After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 631597 - Segmentation fault in append_escaped_text
Segmentation fault in append_escaped_text
Status: RESOLVED NOTGNOME
Product: glib
Classification: Platform
Component: i18n
2.24.x
Other FreeBSD
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2010-10-07 11:37 UTC by D
Modified: 2015-04-28 15:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GDB session with "bt full" after segfault (18.89 KB, text/plain)
2010-10-07 11:37 UTC, D
  Details
0001-gmarkup-Make-append_escaped_text-slightly-more-robus.patch (686 bytes, patch)
2015-04-28 14:56 UTC, Hans Petter Jansson
accepted-commit_now Details | Review

Description D 2010-10-07 11:37:40 UTC
Created attachment 171888 [details]
GDB session with "bt full" after segfault 

I have encountered segfault in recent Gajim 0.14 application. Please have a look at the attachment with backtrace. 

FreeBSD 8.1-RELEASE, Glib 2.24.2, GTK 2.20.1, PyGTK 2.17.0.

The error appears only then I am using "ru_RU.KOI8-R" locale, LC_ALL="C" produces no errors.

The bug was originally reported in http://trac.gajim.org/ticket/5959
Comment 1 Matthias Clasen 2010-10-12 03:48:32 UTC
It appears you have non-utf8 text here. This is not the fault of append_escaped text, but of whoever passed non-utf8 text down there. Looks like it may be coming from a gtkbuilder ui file, or from translations ?
Comment 2 D 2010-10-14 10:44:27 UTC
(In reply to comment #1)
> Looks like it may be
> coming from a gtkbuilder ui file, or from translations ?

Well, as I can guess from the backtrace, "buggy" string is in "data/gui/filetransfers.ui". More precisely - http://trac.gajim.org/browser/data/gui/filetransfers.ui#L198, but this ui file is in english. 
So, the bug comes from translation?
Comment 3 D 2010-10-14 11:22:11 UTC
(In reply to comment #2)
> So, the bug comes from translation?

I have just carried out small test: "ru_RU.UTF-8" locale produces no errors. 
Russian .po file seems to be valid utf-8. 
May be glib internals is somehow affected by locale settings? (I can only conjecture.)
Comment 4 Hans Petter Jansson 2015-04-28 14:52:21 UTC
Looks like the application mistakenly passed a KOI8-R encoded string to GTK. You could probably track this down, or at least get closer, by breaking on g_logv() and investigating the earliest warning you get prior to the crash.

By the way, append_escaped_text() is extra vulnerable to invalid UTF-8 because of this:

> while (p != end) { ... }

Judging by the backtrace, g_utf8_next_char() skipped slightly past end, making the loop go on until it hit an invalid address. This can also happen if you pass a valid UTF-8 string with a too short length argument.

I think it'd make sense to change it to

> while (p < end) { ... }

which would make it more robust and more readable, since the existing assumption is made explicit.
Comment 5 Hans Petter Jansson 2015-04-28 14:56:40 UTC
Created attachment 302518 [details] [review]
0001-gmarkup-Make-append_escaped_text-slightly-more-robus.patch

Make append_escaped_text() slightly more robust.
Comment 6 Matthias Clasen 2015-04-28 15:03:27 UTC
Review of attachment 302518 [details] [review]:

makes sense to me
Comment 7 Hans Petter Jansson 2015-04-28 15:24:00 UTC
Pushed to master. Resolving as NOTGNOME since bug as reported was not caused by glib.