I've seen the same problem. Note that it didn't happen when I disabled
the a11y gconf key.


Here is a stack trace:


Program received signal SIGSEGV, Segmentation fault.

+ Trace 44712

I'm not seeing this problem.  I have a brand new gok, at-spi, and
gnome-control-center.  The rest of my gnome desktop is from Feb 16th.

I wonder if this is a glib problem.  

Patrick, or Peter, can you try an earlier glib?

Just upping the priority...

I just installed glib head and still can't reproduce.  Still looking...

Does this happen on subsequent launches?  (I've seen it only once, and
could not reproduce).

I don't think the "regression" prefix is helpful here.

THis sure looks like a gtk+ problem from the stack trace (and the fact
that it recently surfaced without any changes to the gok startup code).

Bill - this happens consistently on my system.

I think I've tracked down the problem (a separate e-mail from Bill
jogged my brain in the right direction).  I didn't realize the
significance at t6he time, but some days I ago I got a warning message
"You have a keyboard remapping file (.Xmodmap) in your home directory
whose contents will now be ignored.  You can use th ekeyboard
preferences to restore them."  Removing this file and doing a
`gnome-cleanup` fixed whatever wierdnesses were in my configuration. 

Patrick - I recommend you try that, and if that fixes it for you,
close the bug (as I was about to before I saw your comment).

Whew!

Patrick, we're waiting on you ;-)  (

Yes, this appears to be related to the newly described Xmodmap file.
Once this file is renamed, and you've relogged in, gok becomes useable
again.

We should put something in the README.

This workaround doesn't always work (discovered in a new install of
yesterday's build, last night).  However, sometimes the problem "just
goes away" on a subsequent login anyhow.

We still can't reliably reproduce, but this bug is alive and out
there.  The stack trace shows that the problem appears in glib, in a
g_object_set_data call I think - it even happenned in the debugger,
and then it stopped happenning on a subsequent login.  Of course the
root cause could be anywhere, if it's a stray pointer or memory overwrite.

FWIW, sometimes when things get wonky I go to a virtual console, bring
down X, do a bonobo-slay and blow away /tmp/orbit* -- Not sure that is
relevant here...  or if it is even good practise.

I have been experiencing crashes on Solaris with the stack trace
similar to that above.

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

No .Xmodmap on my system where this problem happens every time.  I see
the same stacktrace.  This is running HEAD everything, as of yesterday.

Okay, I still can't recreate this.  I've updated my gtk+ and
libgnomeui and I do get a:
(gok:11151): GLib-GObject-CRITICAL **: file gobject.c: line 1207
(g_object_set): assertion `G_IS_OBJECT (object)' failed

... at start up, but gok continues fine enough...

David,

I have also seen this behavior.

I believe that the problem is with the creation of the Try button in
gok_settingsdialog_open(). If the statement gtk_button_set_label() at
line 143 is commented out then gok starts up.

I have a one line patch for gtkbutton.c which fixes the problem if the
call to gtk_button_set_label() is not commented out. See bug #136259.
In this case the label is set to Try but the stock icon is not
displayed. It looks like gtk+ does not support changing the text
associated with a stock icon. Did this once work?

Should GTK_STOCK_APPLY be used instead of Try?

Padraig: changing a stock icon label did "once work".  Personally I
think changing to use STOCK_APPLY makes sense here however, since even
with your gtk+ patch you pointed out to me that the result would be
that the image in the 'Try' button would be removed by the set-label
command.

I will make the change to use stock apply.  Thanks SO MUCH for
tracking this down!

Fixed in cvs.

Thanks Padraig (I just got in -- so nice to see this fixed guys!)