GNOME Bugzilla – Bug 300423
gnibbles crash on Preferences
Last modified: 2005-07-27 23:46:33 UTC
Distribution/Version: garnome I mentioned this on the gnome games list a while back, again this may be due to my having made a mess of Garnome but I provide the information and leave it for you to decide if it is worth following up. (gdb) run Starting program: /tmp/garnome/bin/gnibbles [Thread debugging using libthread_db enabled] [New Thread 1089196704 (LWP 18310)] Detaching after fork from child process 18313. Detaching after fork from child process 18314. Program received signal SIGSEGV, Segmentation fault.
+ Trace 58105
Thread 1089196704 (LWP 18310)
Both this and your gnometris bug suggest that gconf is in one way or another not doing what it should. I'm thinking that your Garnome install is wack.
it is either a) fucking around with my existing messed up settings or b) garnome is working as I intended and not using my $HOME but hasn't quite managed to create a new set of gconf settings anywhere. If you want to close this as WONTFIX I dont mind but I thought these reports might reveal some potential robustness fixes so that the games would still run even if your gconf settings were completely out of whack (you should see have badly Gnome fucks up if your home directory is on network drive and disappears temporarily, it is freakin insane).
GConf provides absolutely no guarantees about the quality of the data it provides. We shouldn't be crashing if gconf is feeding us crack, so this isn't a WONTFIX bug. However, given the time, it is a "not tonight" bug.
Yes, but the trace says the crasher in this bug isn't gnibbles chocking on crack fed by gconf. Rather, either gnibbles fed gconf crack, or Alan's gconf/garnome install is really somehow beyond repair. This comment doesn't apply to Alan's gnometris bug, though.
Yeah Richard, you're right. It is GConf crashing when we try and get the schema out so we can label the controls in the key configuration menu. Alan: It looks like the schemas are hosed on your system (as opposed to the keys themselves). This isn't an entirely unusual situation with software installed in its own tree. However GConf shouldn't be crapping itself in such circumstances. This will probably also affect gnometris, but the bug you saw there is different - the program hadn't run far enough for it to crash this way.
Actually, I will partly retract my previous statement. Richard: you are right and you are also wrong. The g_str_hash function can only be caused by a bad "key" argument. This is checked at the gconf_client_get () level. So key is either an invalid, but non-NULL reference or it points to a unterminated string at the end of memory. In either case the result actually comes from a previous call to gconf_entry_get_schema_name () which just pulls the result straight out of a gconf_entry without checking. However, the previous call to gconf_engine_get_entry () should have given us an entry with either a) a valid schema name, b) a NULL schema name, or c) have set an error and returned NULL. We check for the error. So we feed gconf crack that it fed to us _without an error being flagged_. It looks like I will have to punt this bug to the gconf guys, but I'm still looking at the code.
*** Bug 300421 has been marked as a duplicate of this bug. ***
I've finally had another look at it. Despite some of the calls we are using being undocumented I'm pretty certain we're doing the right thing. I'm still pretty sure that the problem is gconf_entry_get_schema_name () giving us bad data (of a sort we can't easily detect). So I'm closing this bug as WONTFIX because I don't think its worth punting this to gconf. That is based on the assumption that Alan's gconf setup has been fixed sometime in the last two months and we therefore can't find out where it was going wrong.
Reopening: I have managed to reproduce the bug. In my case it is using gnometris, but it is the same code called in games_controls. I can emulate a hosed gconf system by using mudflap which somehow stops corba working (if you haven't solved your problems Alan: check your ORBit installation). However, it is my bedtime so it will have to be fixed tommorrow.
I have found the bug. We don't check that the gconf engine we request isn't NULL. I had thought that the gconf calls we used checked for a NULL engine and so we could just do error checking at the end. Unfortunately I missed a macro in the gconf code which tried to dereference the engine before the check I thought kept us safe. Looking at the other gconf_engine_* calls I don't think that there is any reason to expect gconf to handle a NULL engine gracefully so I have added an explicit check in our code. This is fixed in my tree. I will upload to CVS HEAD tonight.