From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041129 Firefox/1.0

Description of problem:
After some major grief upgrading my box to FC3 from FC2 last weekend, I'm pinning the blame AFAICS on GConf2.

I had number of nasty gnome-related problems (glitches & crashes) which I've followed up on through judicious debuginfo RPMs [the core install is still runnig smoothly;  all back-end services (mail/hardware/etc.) function perfectly].

The symptoms all seem to stem from  apps. receiving null data back from gconf when reading config. keys.  E.g., gnome-background-properties was crashing reading the current background filename;  metacity's settings are all mostly borked (no key mappings at all, 0 desktops configured (see example error below);  the mulitload-applet seems to do nothing at all (no display, no error), the windowlist applet have major sizing issues [either 0-width or refuses to auto-resize]).  gconf-editor was crashing initially too!

Naturally, I created a fresh account, and also tried an existing dummy account with the home dir. wiped (all * & .[a-z]* wiped);  even these new account exhibit the problems, so just trashing the current .gconf dir. & starting again fixes it.

E.g., with a bl;ank user account, logging in for the 'first' time:

Window manager warning: 0 stored in GConf key /apps/metacity/general/num_workspaces is not a reasonable number of workspaces, current maximum is 36


 .. whereas the metacity schema file [where I believe the defaults come from] distinctly has:

...
    <schema>
      <key>/schemas/apps/metacity/general/num_workspaces</key>
      <applyto>/apps/metacity/general/num_workspaces</applyto>
      <owner>metacity</owner>
      <type>int</type>
      <default>4</default>
...

  What I've determined from debugging is that for the most part gconf_client_get is coming back with no error *BUT* also no value (null pointer) which is mostly where the crashes are coming (e.g., some code is just checking the error arg. [3rd., pointer-return] and not checking the return pointer-value itself before trying to deref. it.

  Within gconf-editor (somehow started working after multiple debug attempts in ddd/gdb), I see a large no. of keys are 'no value' (even type-less), and it's this 'null'/type-less attribute that seems to be causing the apps. to crash.  Certainly, if I double-click one to set it, I get the ability to choose its type, which I don't think's right.


  I can sometimes manage to coax stuff into life now I've managed to get gconf-editor loading (in my account) by setting proper values for the 'dead' ones, but there's something more fundamentally wrong going on here that that's not going to really help, and not eveything is playing ball (e.g., the monitor applet).

No-one else seems to be having this issue, and to be honest I'd pretty much decided that come FC4 I'll do a back-up and a full install instead of an upgrade to clear out all the rubbish (been doing upgrades since my first install of RH6.1 in 2000);  this has made that definite:  I reckon I can muddle through till then, but this is such a major glitch (as I said, but it bears repeating, it's a defaults issue that even new accounts suffer from, although I'm sure some of the settings were OK in my .gconf persionaly setting before - e.g., metacity bindings) I though it warranted a bug report.

Oh yes, and the settings I apply by hand through gconf-editor do seem to stay put once I've done so.


Version-Release number of selected component (if applicable):
GConf2-2.8.1-1

How reproducible:
Always

Steps to Reproduce:
n/a

Additional info:

RPMs:

GConf-devel-1.0.9-15.i386.rpm
GConf2-2.8.1-1.i386.rpm
GConf2-debuginfo-2.8.1-1.i386.rpm
GConf2-devel-2.8.1-1.i386.rpm
gconf-editor-2.8.0-2.i386.rpm
gconf-editor-debuginfo-2.8.0-2.i386.rpm
gconfmm2-2.6.1-1.rhfc2.nr.i386.rpm
gconfmm2-devel-2.6.1-1.rhfc2.nr.i386.rpm
gnome-python2-gconf-2.6.0-3.i386.rpm
pkgconfig-0.15.0-3_4.rhfc3.at.i386.rpm