Summary: | x11/xfce4-taskmanager segfault | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Ivan <bsd> | ||||||
Component: | Individual Port(s) | Assignee: | freebsd-xfce (Nobody) <xfce> | ||||||
Status: | Closed Overcome By Events | ||||||||
Severity: | Affects Only Me | CC: | madpilot, olivierd | ||||||
Priority: | --- | Flags: | madpilot:
maintainer-feedback+
|
||||||
Version: | Latest | ||||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Description
Ivan
2016-08-26 09:59:13 UTC
I'm using FreeBSD 11-RC2 and xfce4-taskmanager works fine. I use the binary package from the latest repository. This problem occurs when ru_RU.UTF-8 used. I have no problems with en_GB.UTF-8 or C. env LANG=ru_RU.UTF-8 xfce4-taskmanager works as well, only when entire X session is started with LANG var. https://git.xfce.org/apps/xfce4-taskmanager/tree/src/task-manager.c#n184 According code and considering bug occurs only when X started with LANG env, I think something bad passed to tree. I use almost pure xfce, so can you try LANG=ru_RU.UTF-8 to see if it's reproducible on your system? If not, I'll try to instrument it with some debug code. (In reply to Ivan from comment #3) I try with ru_RU.UTF-8 and xfce4-taskmanager does not crash. Tested on my 11.0-RC2 machine, where default encoding is fr_FR.UTF-8, and 9.3-RELEASE where encoding is fr_FR.ISO8859-15. Everything is fine. Sometimes encoding can cause crash (on my 9.3-RELEASE machine, xfce4-screenshooter-plugin is broken). xfce4-taskmanager-Message: /usr/local/libexec/xfce4/panel-plugins/xfce4-xkb-plugin 8 18874411 xkb-plugin Раскладки клавиатуры Настройка и переключение клавиатурных раскладок xfce4-taskmanager-Message: xfce4-xkb-plugin xfce4-taskmanager-Message: xfce4-xkb-plugin 8 18874411 xkb-plugin Раскладки клавиатуры Настройка и переключение клавиатур\xd0 Ошибка сегментации(core dumped) See \xd0 after task->cmdline and task->name passed to pretty_cmdline() pretty_cmdline() can generate invalid utf-8 sequence (cutting 2-byte chars on half?). Created attachment 174716 [details]
patch
Problem is here
g_strlcpy (text, p, g_utf8_strlen (text, -1));
To utf-8 unaware function number of chars are passed instead of bytes, so it's possible for 2 bytes chars it will split in half leading to incorrect unicode sequence.
Attached patch resolves the issue, however crash still can occur if p >= text, however as p is substring of text, the situation is expected to never happen in normal conditions.
I found no safe analog in gtk functions for strlcpy, only strncpy which is not considered safe. The alternative is switch to icu, however this is another story.
New version bump erased my local patch and I remembered about this issue. I can make the patch against current port tree if this is necessary or @Olivier Duchateau can commit it as is. I tested it today and it's still to what it does. Created attachment 180531 [details]
QA with synth
(In reply to Ivan from comment #6) > Created attachment 174716 [details] > patch > > Problem is here > g_strlcpy (text, p, g_utf8_strlen (text, -1)); > > To utf-8 unaware function number of chars are passed instead of bytes, so > it's possible for 2 bytes chars it will split in half leading to incorrect > unicode sequence. > > Attached patch resolves the issue, however crash still can occur if p >= > text, however as p is substring of text, the situation is expected to never > happen in normal conditions. > > I found no safe analog in gtk functions for strlcpy, only strncpy which is > not considered safe. The alternative is switch to icu, however this is > another story. Hi, The fix looks simple enough, but I'm not sure that using non utf aware functions is better that using g_utf8_strncpy(), which would warrant utf8 conforming results. also, looking at the g_utf8_strncpy() sources here: https://github.com/GNOME/glib/blob/9c8c6094fdb3b7bff35c0f36a68e1da3fd2e8ff7/glib/gutf8.c#L413 it would be quite easy to cook up a g_utf8_strlcpy() (or any other name) using the safer system provided strlcpy() call. I'd like your opinion before proceeding though. Any patch we prepare should be created accounting for upstreaming it if possible. Hi, Looking at this bug report, it looks like the upstream code referenced here has undergone extensive changes with the latest releases, here are two relevant upstream commits: https://gitlab.xfce.org/apps/xfce4-taskmanager/-/commit/fd9e313e2e89ed0b81bec8c491842e7032e797ac https://gitlab.xfce.org/apps/xfce4-taskmanager/-/commit/b89684865d88bbb8399f70387cae9e8ae17d64d9 I'd like to close this one, and will do that in a few days unless prompted not to do so. Thanks! The code causing this crash has been completely rewritten by upstream with recent updates. So this bug does not apply anymore. |