Created attachment 5191 xfce4-taskmanager-Invalid_UTF-8_string.patch (copy from Gentoo bug tracker https://bugs.gentoo.org/show_bug.cgi?id=488626) xfce4-taskmanager-1.0.0 compiled fine, but after start, generate a lot if "(xfce4-taskmanager:32218): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()" warnings and take 100% CPU time on my ARM box. Also found this issue in fedoraproject list: https://lists.fedoraproject.org/pipermail/arm/2012-September/003988.html I did some investigation, and compiled code with all warnings enabled. One of warnings was connected to issue: task-manager-linux.c: In function ‘get_task_cmdline’: task-manager-linux.c:139:2: warning: comparison is always true due to limited range of data type [-Wtype-limits] The problem was in line: for (i = 0; (c = fgetc (file)) != EOF && i < (gint)sizeof (task->cmdline) - 1; i++) where "c" - is char, and this is the point of issue. I create patch and test it with epatch_user feature - work fine on amd64 and arm.
Created attachment 5691 Fix-UTF-8-strings-in-the-pretty_cmdline.patch I think this patch is good, but it does not fix the bug. There are 2 problems in the pretty_cmdline() function: 1. g_utf8_strlen() returns length of the string in characters, not in bytes. So this value can not be used as argument for snprintf(). 2. snprintf() can not be used with overlapping buffers (C-11 standard, 7.21.6.5 paragraph 2). Attached patch should fix the bug.
Re attachment 5691 , i was having a crash on that line on OpenBSD and fixed it by using g_strlcpy() in http://git.xfce.org/apps/xfce4-taskmanager/commit/?id=59ed589b2640a1b2d2fce4bd571eda0b6361f1e2 - can you check it fixes some issues for you ? The pango warning is still shown but at least it doesnt crash for me at startup.
*** Bug 10496 has been marked as a duplicate of this bug. ***
Looking again at attachment 5191 , it probably fixes a bug, right, but i fail to see why itd fix the pango warning.... Oh, and since i can only test on OpenBSD, i'll try you guys on the testing for this on Linux (if its already in gentoo...) but i doubt that fixes the root issue here. Can anyone confirm all the warnings are gone with that patch applied on top of git master ?
of course i meant 'trust' and not 'try'....
Unfortunately, I can't test this patch on ARM box any more (sold it). Btw, I faced with this Pango-related issue only on ARM (ARMv7 hard-float), and was not able to reproduce it on x86 or amd64 gentoo. I have tested all patches (http://bug-attachment.xfce.org/attachment.cgi?id=5691 and http://git.xfce.org/apps/xfce4-taskmanager/commit/?id=59ed589b2640a1b2d2fce4bd571eda0b6361f1e2) on amd64 gentoo, but, since I can't reproduce previous issue, this give us nothing. I have no warnings with or without patches on amd64 gentoo. :(
Applied attachment 5191 in 97f974f - closing bug since all patches were landed, but i think the root issue in the bug subject is still here, and unrelated to those patches.
(In reply to Landry Breuil from comment #2) > Re attachment 5691 , i was having a crash on that line on OpenBSD > and fixed it by using g_strlcpy() No, this bug can't be fixed in this way. UTF8 characters can be 2+ bytes wide. g_utf8_strlen() returns length of a string in _characters_ (NOT IN BYTES!) and this value can't be used as 'size' argument for strlcpy(). For example, if we have UTF8 string 5 characters long and 2 of them are 2 bytes wide, then length of the string in bytes will be 7 + 1 for NUL in the end. g_utf8_strlen() will return 5 for this string, and strlen() will return 7. And if we use g_strlcpy() with 'size' value returned by g_utf8_strlen() then string will be truncated. And even worse, it can cut a 2 bytes UTF8 character in the middle. And a half of an UTF8 character is not a valid UTF8 character, of course, and that's why pango_layout_set_text() complains afterward. And g_strlcpy() must never be used for overlapping buffers too, that's why I use memmove() in my patch. Alternatively, one can allocate memory for new string, copy part of the string and use this new string.