GNOME Bugzilla – Bug 681837
Make enum type registration thread safe
Last modified: 2013-04-12 07:53:59 UTC
I get this crash quite often, and because it's a recent change, then I do not think it's an old thing. The console is full of critical warnings: (evolution:6626): GLib-GObject-WARNING **: cannot register existing type `EEwsFolderType' (evolution:6626): GLib-GObject-WARNING **: cannot retrieve class for invalid (unclassed) type `<invalid>' (evolution:6626): GLib-GObject-WARNING **: cannot register existing type `EEwsFolderType' (evolution:6626): GLib-GObject-WARNING **: cannot retrieve class for invalid (unclassed) type `<invalid>' I suppose it's some linking issue. I get this when I run all evolution processes from scratch (none DBus service is running when I run evolution), though I do not think this has anything to do with it. Note I have EWS account enabled.
+ Trace 230670
Thread 9 (Thread 0x7f14ea417700 (LWP 6661))
I haven't seen this yet myself. I introduced the GType for EEwsFolderType recently after I caught the "folder-tree" file storing enum values numerically, which is bad. http://git.gnome.org/browse/evolution-ews/commit/?id=3b1b92a4ad3deaa95c0b848415101f03c315b476
It's for me one of two/three runs, sometimes more succeed, then other die. I always close everything (factories and source registry included) and run evolution from scratch.
Just an update on this: it is shown for me mostly if I run in mailer with selected EWS' Inbox folder. Basically: a) make sure you have selected EWS' Inbox before closing evolution b) close all evolution processes c) run evolution in mailer (evolution -c mail) d) wait till the initial password check is done, then EWS folders are loaded and the Inbox is likely to be selected, but instead, console is full of warnings like in comment #0 and evolution either crashes or shows almost no EWS folder. If I change folder before they are loaded, like if I select On This Computer/Inbox, then I can select EWS' Inbox afterwards with no issue. Again, this is timing related.
Created attachment 241287 [details] [review] ews patch for evolution-ews; OK, even the previous steps were not enough, it was pretty inconsistent for me to reproduce this. I thought that this is caused by a library reload, the ews lib, but it isn't it. I managed to reproduce this under gdb, finally, and evolution was partly consistently claiming the issue on the already registered type. The reason is that the two threads were calling e_ews_folder_type_get_type() in the same time, and for the first time, but the function as such is not thread safe, thus this thread interleave caused the crash. I'm fixing the .template file, to make it thread safe, in ews and other evolution related sources as well.
+1 Nice catch.
Created attachment 241289 [details] [review] ews patch ][ for evolution-ews; This change is even better, I can use one template to generate any enum types, which I will simply reuse in evo and eds, instead of copy templates around the sources (within one tree).
Created commit 5fbcfaf in ews master (3.9.1+) Created commit d3ed6d9 in ews gnome-3-8 (3.8.1+) (I'll do the other evolution core products tomorrow, battery is low.) :-/
Err, EXTRA_DIST required a change too, thus commit a866d03 on master and commit bd81fd0 on gnome-3-8.
Created commit 5e858bb in eds master (3.9.1+) Created commit 1c5f631 in evo master (3.9.1+) Created commit f41d408 in eds gnome-3-8 (3.8.1+) created commit 8c25144 in evo gnome-3-8 (3.8.1+)