Something is odd here. The line  gnome-kbd-indicator.c:266 is empty (in cvs.gnome.org). Could you please attach the sources you used? Also, what is your XKB configuration and which version of xkeyboard-config do you use?

Is it possible that this was due to temporary version skew between control-center and gnome-applets ?

It works fine on my two test machines today, with gnome-applets 2.15.3 and
control-center 2.15.91.

Dunno, maybe best to close this for now, if nobody else sees this.

Yes, it looks like a skew...

*** Bug 357500 has been marked as a duplicate of this bug. ***

The duplicate indicates this is likely not just version skew, and we also have a report in openSUSE 10.2 with gnome 2.16.1 now:

https://bugzilla.novell.com/show_bug.cgi?id=216201

With a bit better trace.

The crash is because in the code below if gswitchit_config_get_remote_lv_descriptions_utf8 fails, short_group_names is never allocated, would would set globals.short_group_names to a valid pointer.  globals.short_group_names is latter dereff'ed and *boom*.  Allocation short and group names of length 0 plus NULL terminator in the stringv should prevent the crash at least.  I'll poke to see gswitchit_config_get_remote_lv_descriptions_utf8 fails on openSUSE.

gboolean
gswitchit_config_load_remote_group_descriptions_utf8 (GSwitchItConfig *
                              config,
                              gchar ***
                              short_group_names,
                              gchar ***
                              full_group_names)
{
    gchar **sld, **lld, **svd, **lvd;
    gchar **psld, **plld, **plvd;
    gchar **psgn, **pfgn;
    gint total_descriptions;

    if (!gswitchit_config_get_remote_lv_descriptions_utf8
        (&sld, &lld, &svd, &lvd)) {
        return False;
    }

    total_descriptions = g_strv_length (sld);

    *short_group_names = psgn =
        g_new0 (gchar *, total_descriptions + 1);
    *full_group_names = pfgn =
        g_new0 (gchar *, total_descriptions + 1);

It seems your diagnistics is right.

But there are several questions here:
1. Why get_remote_lv_descriptions fail? what's wrong with DBUS/g-s-d or smth?
2. Wouldn't it be better to keep short_group_names NULL and process this situation correctly.

I am going to think about #2 - but do you have any idea about #1?

I committed the code (to gnome-2-16 branch) which should make processing of NULL in short_group_names correct. JP, could you please check?

This bug (I think it is the same) also appears in Fedora Core 6.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213419

Using gnome-applets-2.16.0.1-10.fc6.i386

Sergey, could you post (or link to) your patch? 

Jon, if you just take the latest version of gnome-kbd-indicator.c (according to http://cvs.gnome.org/viewcvs/libgswitchit/?only_with_tag=gnome-2-16 , it is 1.14.2.4) - you'll have it.

Sergey-

No luck, I recompiled using v1.14.2.4 of gnome-kbd-indicator.c and I still get a seg fault upon adding a second keyboard.

Could it be that your fix is not related to the bug I reported here: ?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213419

Let me tell you what I did, let me know if I did something wrong.  I am willing to keep testing in any way you want to find the solution to this problem.

1) I downloaded the source RPM from Red Hat's current FC6 gnome-applets (gnome-applets-2.16.0.1-10.fc6.i386).

2) I installed using "rpm -Uvh gnome-apple..."

3) I went over to /usr/src/redhat/SOURCES and untarred the appropriate tar.bz2 file

4) I downloaded the v1.14.2.4 of gnome-kbd-indicator.c as per your instructions and replaced the file of the same name in 
/usr/src/redhat/SOURCES/gnome-applet... then I re-tarred the directory overwriting the old gnome-applets....rar.bz2 file

5) I recompiled the by issueing a "rpmbuild -ba /usr/src/redhat/SPEC/gnome-applets.spec" (had to edit out patch #25, which applies to gnome-kbd-indicator.c) which should rebuild using the new code.

6) Reinstall the newly created RPM 

Suggestions?

Well, may be you just hit the second bug on your way;)

About xkl_config_rec_dump - there is another open bug here. But the problem is that the stack trace as it is - does not make any real sense... So I am trying to understand why and how it may happen... So, your current situation looks like DUPLICATE...

OKay, so does that mean you need to reopen this bug (#351395), or is there another I should be tracking?

*** This bug has been marked as a duplicate of 370038 ***