After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 119755 - Crash on start up
Crash on start up
Product: conglomerate
Classification: Other
Component: Code
Other other
: Normal critical
: ---
Assigned To: conglomerate list
conglomerate list
Depends on:
Reported: 2003-08-13 06:18 UTC by Christopher Warner
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Christopher Warner 2003-08-13 06:18:49 UTC
Package: conglomerate
Severity: critical
Version: 0.5.4
Synopsis: Crash on start up
Bugzilla-Product: conglomerate
Bugzilla-Component: general

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
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/

Expected Results:

Should start up

How often does this happen?

All the time

Additional Information:

PPC Ibook.

------- Bug moved to this database by 2003-08-13 02:18 -------

Reassigning to the default owner of the component,

Comment 1 David Malcolm 2003-08-13 08:46:09 UTC
Please can you attach a backtrace from GDB?  I haven't seen this
behaviour before.
Comment 2 Geert Stappers 2003-08-13 09:20:40 UTC
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.

Thread 16384 (LWP 7843)

  • #0 gconf_client_get_type
    from /usr/lib/
  • #1 gconf_client_get_default
    from /usr/lib/
  • #2 cong_app_destroy_singleton
  • #3 cong_app_construct_singleton
  • #4 main
  • #5 __libc_start_main
    from /lib/

Comment 3 Christopher Warner 2003-08-13 17:26:13 UTC
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.

  • #0 set_engine
    from /usr/lib/
  • #1 gconf_client_get_default
    from /usr/lib/
  • #2 cong_app_new
    at cong-app.c line 99
  • #3 cong_app_construct_singleton
    at cong-app.c line 58
  • #4 main
    at main.c line 316
  • #5 __libc_start_main
    at ../sysdeps/powerpc/elf/libc-start.c line 178

Comment 4 David Malcolm 2003-08-13 17:51:14 UTC
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?
Comment 5 Christopher Warner 2003-08-13 20:25:52 UTC
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
Comment 6 David Malcolm 2003-08-13 23:00:47 UTC
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

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.
Comment 7 Boris Goldowsky 2003-08-14 13:22:32 UTC
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.
Comment 8 Christopher Warner 2003-08-14 17:18:09 UTC
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.
Comment 9 Christopher Warner 2003-08-14 17:19:41 UTC
Ugh, forgot to bounce back to Conglomerate in the meantime.
Comment 10 Geert Stappers 2003-08-14 17:58:22 UTC
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)
Comment 11 Oleg Paraschenko 2003-08-30 19:36:54 UTC
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*
	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,

I added call to g_type_init(). Program runs now.
Comment 12 Geert Stappers 2003-09-04 07:04:24 UTC
the extra line is in CVS and marked with 'GSt'
Comment 13 David Malcolm 2003-09-05 15:36:58 UTC
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...
Comment 14 Geert Stappers 2003-09-06 13:50:06 UTC
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.
Comment 15 Geert Stappers 2003-09-19 10:11:09 UTC
More people that are willing to confirm the fix?
Comment 16 Geert Stappers 2004-07-09 08:09:34 UTC
closing it.