GNOME Bugzilla – Bug 119755
Crash on start up
Last modified: 2009-08-15 18:40:50 UTC
Package: conglomerate Severity: critical Version: 0.5.4 Synopsis: Crash on start up Bugzilla-Product: conglomerate Bugzilla-Component: general Description: Description of Problem: Conglomerate crashes on startup Steps to reproduce the problem: 1. Compile Conglomerate 2. Start it up. Actual Results: Starting program: /usr/local/bin/conglomerate [New Thread 16384 (LWP 28090)] (process:28090): GLib-GObject-CRITICAL **: gtype.c:1875: initialization assertion failed, use g_type_init() prior to this function (process:28090): GLib-GObject-CRITICAL **: file gobject.c: line 615 (g_object_new): assertion `G_TYPE_IS_OBJECT (object_type)' failed (process:28090): GLib-GObject-CRITICAL **: file gobject.c: line 1319 (g_object_ref): assertion `G_IS_OBJECT (object)' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 28090)] 0x0fc3fea0 in set_engine () from /usr/lib/libgconf-2.so.4 Expected Results: Should start up How often does this happen? All the time Additional Information: PPC Ibook. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-08-13 02:18 ------- Reassigning to the default owner of the component, conglomerate-auto@lists.copyleft.no.
Please can you attach a backtrace from GDB? I haven't seen this behaviour before.
As a regular user I'm not able to reproduce it. However, when I'm <i>root</i> is it reproducable. (process:7843): GLib-GObject-CRITICAL **: gtype.c:1871: initialization assertion failed, use g_type_init() prior to this function (process:7843): GLib-GObject-CRITICAL **: file gobject.c: line 615 (g_object_new): assertion `G_TYPE_IS_OBJECT (object_type)' failed (process:7843): GLib-GObject-CRITICAL **: file gobject.c: line 1319 (g_object_ref): assertion `G_IS_OBJECT (object)' failed (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault.
+ Trace 39555
Thread 16384 (LWP 7843)
BT looks a little different for me, it doesn't even start as a regular user for me. However, I have seen the reported behavior of it crashing only as root.
+ Trace 39563
OK - it's dying inside the call to gconf_client_get_default, which is alarming. Is your GConf install working? Do other applications that use GConf work on your machine? What happens if you run gconf-editor?
Yeah my Gconf apps work fine.. gconf-editor works fine.. now when I run conglomerate everything is peachy as root and a regular user. I had to run gconf-editor though, just run it; make no changes. The only thing I can think of is that Gconf corrupts relevant keys somewhere. Let me know if you need me to try and reproduce certain behavior.
That's odd. I just had a look through the gconf-editor sources, and as far as I can tell, the first call it makes to GConf is in src/gcong-tree-model.c, in the instance init function, where it also calls gconf_client_get_default... So both apps are doing the same thing, as far as GConf is concerned - the initial call to gconf_client_get_default I'm reassigning the "product" of this bug to GConf in the hope that someone more knowledgable about the GConf internals can give me a clue as to what might have gone wrong. Feel free to bounce it back to Conglomerate if you think it's my bug.
I get this crash as well. Some additional information: Immediately after running "make install" on conglomerate, it will run successfully as the user who did the install, but not as another user. After the other user runs (and immediately exits) gconf-editor, it works fine. Re-running "make install" will reset it to the broken state.
Ok then it has to be something with Conglomerate.. Does it modify anything involving Gconf on install?? If anything it's going to be a problem in cong-plugin.c. I'll have a little look later myself to see if there is anything.
Ugh, forgot to bounce back to Conglomerate in the meantime.
The `make install` is generate by automake. We are using version 1.4. There are more recent version of automake, e.g. 1.5 What I try to say is that the cause doesn't have be cong-plugin.c and I some day want to move to automake1.5 (rightnow it has no priority to me)
I had the exactly same problem. I fixed it by modification of source code: cong-app.c, near line 115 /* Internal function definitions: */ static CongApp* cong_app_new(void) { CongApp *app; app = g_new0(CongApp,1); app->private = g_new0(CongAppPrivate,1); /* Set up usage of GConf: */ >>>>>>>> g_type_init(); <<<<<<<<<<< app->gconf_client = gconf_client_get_default(); gconf_client_add_dir (app->gconf_client, "/apps/conglomerate", GCONF_CLIENT_PRELOAD_NONE, NULL); I added call to g_type_init(). Program runs now.
the extra line is in CVS and marked with 'GSt'
Ooops.... I just spotted the problem (I think). I was calling the gconf stuff in cong-app.c before the call to gnome_program_init in main.c I've now moved the call to gnome_program_init into cong-app.c, before the gconf stuff (and removed Geert's call to g_type_init, it shouldn't be needed anymore) If you grab the CVS version, I hope this crash should be fixed. Please can people verify that his works now...
Okay. With the patch from Dave ( actually a CVS update ) I'm not able to reproduce the bug. In other words: it works fine. For the record: The credits of "Geert's call to g_type_init" should go the Oleg Paraschenko.
More people that are willing to confirm the fix?
closing it.