getting a stacktrace from the register error

"GLib-GObject-WARNING **: cannot register existing type `CompEditor'
aborting...

Program received signal SIGTRAP, Trace/breakpoint trap.
IA__g_logv (log_domain=<value optimized out>, log_level=G_LOG_LEVEL_WARNING, 
    format=0x13f3568 "cannot register existing type `%s'", args1=0xbfffdcec "M\243\237\5")
    at /build/buildd/glib2.0-2.21.6/glib/gmessages.c:512
512	/build/buildd/glib2.0-2.21.6/glib/gmessages.c: Aucun fichier ou dossier de ce type.
	in /build/buildd/glib2.0-2.21.6/glib/gmessages.c
(gdb) bt

+ Trace 217409

Can you set a breakpoint on "comp_editor_get_type" and get a stacktrace from the very first call to this after the program starts (before the warning)?

GType registration errors like this are usually due to some GTypeModule registering the type, the module is then unloaded which resets all static variables, then something in the main program registers the same type.

So the usual "get_type" pattern breaks because "type" is reset to 0, so the next call after that tries to register a second "CompEditor" type, which fails.

   GType
   comp_editor_get_type (void)
   {
           /* This is reset when a GTypeModule triggers a
              type registration and then gets unloaded. */
           static GType type = 0;

           if (G_UNLIKELY (type == 0)) {
                   /* register a static GType */
           }

           return type;
   }

the first stop on this symbol is when double clicking on a memo note

"Breakpoint 1, comp_editor_get_type () at comp-editor.c:179
179	G_DEFINE_TYPE (CompEditor, comp_editor, GTK_TYPE_WINDOW)
(gdb) bt

+ Trace 217412

the break point is called some ten times before the warning

Interesting, so the main loop is already started on the first breakpoint.
The modules are all unloaded (I think) before the main loop starts.

Are the memos being added to the "On The Computer / Personal" memo list?

Also, is the breakpoint always occurring in Thread #1?  Nothing but the main loop thread should be creating memo editors.

the config used had no memo before trying to step there, the memos have been added using the text entry just by tapping some random text and enter twice and the category used is the personal computer one

the breakpoint before the warnings

"Breakpoint 1, comp_editor_get_type () at comp-editor.c:179
179	G_DEFINE_TYPE (CompEditor, comp_editor, GTK_TYPE_WINDOW)
(gdb) bt

+ Trace 217413

---Type <return> to continue, or q <return> to quit---param_values=Quit
(gdb) c
Continuing.
[Thread 0xb7cd3b70 (LWP 10691) exited]

(evolution:10674): GLib-GObject-WARNING **: cannot register existing type `CompEditor'

(evolution:10674): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(evolution:10674): calendar-gui-CRITICAL **: e_comp_editor_registry_add: assertion `IS_COMP_EDITOR (editor)' failed

Breakpoint 1, comp_editor_get_type () at comp-editor.c:179
179	G_DEFINE_TYPE (CompEditor, comp_editor, GTK_TYPE_WINDOW)
"

the issue only happens when building with -Bsymbolic-functions

Rescoping this as a build issue.

We encontered the same problem on Solaris recently. Yes, it can be fixed by modifying build option. But the real cause is that both libevolution-calendar.so and libevolution-cal-shared.so have their own copy of comp_editor_get_type (because they both staticlly link to libcal-dialogs.la).

And comp_editor_get_type uses a static function variable to make sure that the type is only registered once. But because every comp_editor_get_type has its own static variable, so the type are registered twice and leads to hang because some code should only be executed once.

I suggest modifying libcal-dialogs.la to make it a dynamic library.

This problem can not be reproduced for trunk because libevolution-cal-shared.so has been removed.

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

I'm not going to do anything to fix this so closing as WONTFIX.

Don't use -Bsymbolic-functions.

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