With 0.5.5, if i only have only layout configured, the plugin crashes when i click on the flag. #0 strlen (str=0x5f746c61 <Address 0x5f746c61 out of bounds>) at /usr/src/lib/libc/string/strlen.c:43 43 for (s = str; *s; ++s) (gdb) bt #0 strlen (str=0x5f746c61 <Address 0x5f746c61 out of bounds>) at /usr/src/lib/libc/string/strlen.c:43 #1 0x07169c79 in g_strconcat () from /usr/local/lib/libglib-2.0.so.3600.1 #2 0x1c00bb17 in xkb_util_get_flag_filename () #3 0x1c00c27d in xkb_plugin_set_tooltip () wild guess,i 'd say the group_name null check is wrong. Will try adding dbg info.
After adding some debug code and a check on strlen(group_name), it appears that the case then group_name is empty (but not null) is not handled, and even if handled and returning null, the plugin still crashes.
Added some debug in xkb_config_get_current_group() : Without a config (so only one layout, setxkbmap fr), the plugin still crashes when clicking on it, at that moment group is 1. For all the previous calls (ie for example mouseover, which correctly sets the tooltip) it was 0.
On a sidenote: with 0.5.4.3 and the same configuration, if you click on the plugin it switches to an empty button/tooltip (so it tries to switch to smth anyway), reclicking comes back to the only configured layout. So something in 0.5.5 made it crash, but the behaviour was already erratic before..
Correction, 0.5.4.3 also crashes in the same conditions.
Well, for starters - I can't reproduce this (not really surprising). Second, the only way of getting this sort of stack trace that I can see is if there is a mismatch between what the xkb-plugin thinks the current xkb config is and what xklavier thinks of the same. What is your xkb-plugin's config (it's probably in ~/.config/xfce4/panel/xkb-plugin-XXX.rc)? What does "setxkbmap -query" returns? Does this problem persist across xkb-plugin restarts? How about X Window restarts?
$setxkbmap -query rules: base model: pc105 layout: fr i start without an xkb config, and it's persistent across reboots/session restarts/panel restarts. And i'm not surprised you cant reproduce it outside of OpenBSD, our stricter memory management/allocation often uncovers bugs/use after free/buffer overflows. So this might be subtle.
I somewhat doubt this has much to do with the extra boundary checking in BSD - the crash is clearly caused by the buffer overrun in the group_name, but the point is that this overrun can only happen if xlkavier reports the XKB group that xkb-plugin is not aware of (well, at least as far as I can see). Assuming you can attach gdb to the running instance of xkb-plugin, try setting a breakpoint in xkb_config_get_current_group() and check what xkl_engine_get_current_state() returns - my guess is that it's returning a group number higher than 0... BTW, I assume that xkb-plugin does show the french flag when it's started (and before you click on it), right?
As i said that's exactly what happens, just before the crash it's 1 instead of 0. And yes at startup it correctly shows only the french flag.
Created attachment 5054 xklavier test Right, and as I said - this shows that the root cause for the crash seems to be libxklavier's misbehavior on your system ;) To demonstrate that, try compiling the attached bug_10128_xklavier.c - it uses libxklavier directly so you'll see this behavior even without xkb-plugin running (at least that's my guess). Note what xkl_engine_get_next_group() returns - if you see it returning 1, it's probably a good idea to file a bug against libxklavier. If you already have libxklavier sources checked out, the easiest way to compile this against them is to put this file into "tests" directory and add it to noinst_PROGRAMS in Makefile.am
[1370295044,000,test_config.c:main/] original layouts: fr xkl_engine_get_next_group returned 1
Created attachment 5055 patch for the crash Precisely, and this is not caused by xkb-plugin (the same code returns 0 on my system if I use your XKB setup, i.e., french layout only). BTW, what this test code does is exactly what happens when you click on xkb-plugin's flag - xkb-plugin just goes to xklavier and asks it to switch to the next XKB group (by calling xkb_config_next_group). Since you have only one layout in your setup (french), this is supposed to be a no-op, i.e., xkl_engine_get_next_group() is supposed to return 0. That said, it's easy to work around this particular crash in xkb-plugin (the attached patch should hopefully be all that's needed) but xkb-plugin relies on libxklavier for nearly all XKB interactions so things are likely not to go very smoothly one way or another if the latter is "lying" about the current XKB settings.
adding a debug call to xkb_engine_get_num_groups() it returns 2, which seems weird. [1370298897,000,test_config.c:main/] original layouts: fr xkl_engine_get_next_group returned 1 xkl_engine_get_num_group returned 2 And if i set a second layout, it still returns 2. [1370299034,000,test_config.c:main/] original layouts: fr et xkl_engine_get_next_group returned 1 xkl_engine_get_num_group returned 2
Yeah, xkl_engine_get_num_groups() returns 1 for me with the same setup (i.e., french layout only)...
http://git.xfce.org/panel-plugins/xfce4-xkb-plugin/diff/?h=4.10_panel_support&id=5efe92e830c77fbe97fea6c11e50827599b3f43a -> fwiw, this doesnt fix the crash, still blows with that backported.
(In reply to comment #14) > still blows with that backported. Hmm, do you get the same stack trace as before or is it something new this time? I tried to test this by faking the group number returned by xkl_engine_get_current_state() and the patch seems to have helped...
The g_assert was triggering, thus causing the crash.. if i remove it, indeed there's no more crash. I have a potential fix in our xkb distribution to actually fix the group count for good.
There was indeed an issue in our xkeyboard-config which got fixed here : http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-xenocara/commit/?id=2f8d51879902baee2bf0746167f352d4dc1f2c08 Still, i think g_assert should be a g_warning to avoid aborting if hit...
(In reply to comment #17) > Still, i think g_assert should be a g_warning to avoid aborting if hit... Done - thanks for reminding me.