I'm setting laptop with FreeBSD and xfce. However, taskmnager is crashing immediately after start. I tried GTK2 and GTK3 option.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 80a416000 (LWP 101105/xfce4-taskmanager)]
0x00000008037f7a5f in strlen () from /lib/libc.so.7
#0 0x00000008037f7a5f in strlen () from /lib/libc.so.7
#1 0x00000008037c6ca2 in strcoll_l () from /lib/libc.so.7
#2 0x0000000802b16ee9 in g_utf8_collate () from /usr/local/lib/libglib-2.0.so.0
#3 0x0000000800e3a8b8 in _gtk_tree_data_list_compare_func () from /usr/local/lib/libgtk-x11-2.0.so.0
#4 0x0000000800d53ed5 in gtk_list_store_insert_with_values () from /usr/local/lib/libgtk-x11-2.0.so.0
#5 0x0000000800d52687 in gtk_list_store_set_valuesv () from /usr/local/lib/libgtk-x11-2.0.so.0
#6 0x0000000800d52833 in gtk_list_store_set_valist () from /usr/local/lib/libgtk-x11-2.0.so.0
#7 0x0000000800d52cbb in gtk_list_store_set () from /usr/local/lib/libgtk-x11-2.0.so.0
#8 0x0000000000413f05 in model_add_task ()
#9 0x0000000000413791 in xtm_task_manager_update_model ()
#10 0x0000000000409a5e in init_timeout ()
#11 0x00000000004094a7 in main ()
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.
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 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]
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]
> 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.
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:
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.