Description of problem: libedataserver.so is broken. I have Thunderbird addon that uses jsctypes to call e_source_registry_new_sync from libedataserver.so. Once method gets called below output is printed and application stucks: (thunderbird:2735): GLib-GObject-WARNING **: cannot register existing type 'EDBusSource' (thunderbird:2735): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed (thunderbird:2735): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed (thunderbird:2735): GLib-GObject-WARNING **: invalid cast from 'EDBusSourceProxy' to '<invalid>' Version-Release number of selected component (if applicable): evolution-data-server-3.12.11-1.fc21 How reproducible: Thunderbird 31.5 with Lighting and EDS Calendar Integration evolution-data-server-3.12.11-1.fc21 Steps to Reproduce: 1. Start thunderbird Actual results: Blank screen is displayed Expected results: libedataserver should return new ESourceRegistry when e_source_registry_new_sync is called Additional info: Works fine on Ubuntu. Tested also with libedataserver downloaded from archlinux (version 3.12.11-1) and it also works fine.
Stack trace to "cannot register existing type 'EDBusSource'" as this seems to be the place where issue starts: g_logv() at gmessages.c:1,046 0x7fffeef30c60 g_log() at gmessages.c:1,079 0x7fffeef30e9f check_type_name_I() at gtype.c:759 0x7fffef24985d g_type_register_static() at gtype.c:2,733 0x7fffef249b0d g_type_register_static_simple() at gtype.c:2,701 0x7fffef249d3d e_dbus_source_get_type() at e-dbus-source.c:282 0x7fffc15fe5ba e_dbus_object_get_source() at e-dbus-source.c:5,980 0x7fffc1605b60 source_initable_init() at e-source.c:1,725 0x7fffcd8cf58c g_initable_new_valist() at ginitable.c:228 0x7fffee3130fa g_initable_new() at ginitable.c:146 0x7fffee3131e6 e_source_new() at e-source.c:2,158 0x7fffcd8ccd71 source_registry_new_source() at e-source-registry.c:663 0x7fffcd8dfc18 source_registry_object_manager_thread() at e-source-registry.c:1,072 0x7fffcd8dfddc g_thread_proxy() at gthread.c:764 0x7fffeef507b5 start_thread() at pthread_create.c:310 0x7ffff7bc652a clone() at clone.S:109 0x7ffff6ed079d
(In reply to balbusm from comment #0) > (thunderbird:2735): GLib-GObject-WARNING **: cannot register existing type > 'EDBusSource' Thanks for a bug report. The above runtime warning usually means that some library tries to register some type multiple times, even from multiple threads (I suggest to use "t a a bt" when that happens). > Expected results: > libedataserver should return new ESourceRegistry when > e_source_registry_new_sync is called It works flawlessly in Evolution, the function is called there as well. Maybe the Thunderbird add-on should be rebuilt? Though there was no API change in the 3.12.x evolution-data-server, thus it might not be needed. I installed these packages: thunderbird-31.5.0-1.fc21.x86_64 thunderbird-lightning-3.3-5.fc21.x86_64 then I found and installed the EDS integration Add-on (0.4.1), then even restarted the thunderbird with that add-on enabled, but I do not get the error you see. Somehow, I also do not get any EDS calendar sources in the lightning view (Calendar and Tasks), which makes me think that something doesn't work, but the thunderbird console shows only this for me: [calBackendLoader] Using libical backend at /usr/lib64/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical.manifest
Thanks for a reply. > The above runtime warning usually means that some > library tries to register some type multiple times, even from multiple > threads (I suggest to use "t a a bt" when that happens). That's correct. I see that "EDBusSource" is registered twice. I wrote simple C app that calls e_source_registry_new_sync. It works perfectly fine. App executes in exacly same way. It tries to register "EDBusSource" multiple times, but consecutive attempts are ignored. In addon case few attempts are ignored, but last one. > Maybe the Thunderbird add-on should be rebuilt? Addon is written in JavaScript and uses js-ctypes. js-ctypes is a Mozilla wrapper on libffi to call C methods from JS. > Somehow, I also do not get any EDS calendar sources in the > lightning view (Calendar and Tasks), which makes me think that something > doesn't work You can enable logging: 1. Thunderbird Menu > Preferences > Preferences > Advanced > Config Editor 2. Set "extensions.edscalendar.logging.enabled" as true This addon synchronizes calendar events with date time indicator (one on top black status bar): 1. Add new event in Thunderbird 2. Click on time indicator 3. You should see newly added event. I'm using exacly the same versions, but I'm getting this bug. I belive it works for you. Are you testing it on default Fedora 21 x64 workstation instalation? Maybe you have some 3rd party packages that inpackt this bug?
I tried it on my work machine, where I also compile evolution from git master. Then I also tried it with an "unaffected" Fedora 21 installation, up-to-date as of today, and I see what you described here, all stock Fedora packages.
Further investigation: I have installed evolution-ews in the fresh Fedora 21. If I uninstall it, then the thunderbird runs without any issue. Do you also have either evolution-ews or evolution-mapi installed?
You are right. I uninstalled evolution-ews (evolution-mapi is not installed) and Thunderbird works like a charm. What does it mean? It is a bug in evolution-ews, libedataserver or addon?
I'm still investigating. I see that thunderbird tries to load libedataserver-1.2.so.17 from here: #0 0x00007ffff79bc0a0 in __dlopen (file=0x7fffd8622220 "libedataserver-1.2.so.17", mode=1) at dlopen.c:75 #1 0x00000032b2614dbb in PR_LoadLibraryWithFlags () at /lib64/libnspr4.so #2 0x00007ffff42288f5 in js::ctypes::Library::Create(JSContext*, JS::Value, JSCTypesCallbacks*) () at /usr/lib64/thunderbird/libxul.so #3 0x00007ffff4228ae7 in js::ctypes::Library::Open(JSContext*, unsigned int, JS::Value*) () at /usr/lib64/thunderbird/libxul.so #4 0x00007ffff448c02f in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () at /usr/lib64/thunderbird/libxul.so #5 0x00007ffff449a9c5 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) () at /usr/lib64/thunderbird/libxul.so #6 0x00007ffff43f8ec8 in js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) () at /usr/lib64/thunderbird/libxul.so #7 0x00007ffff444bd6d in js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) () at /usr/lib64/thunderbird/libxul.so #8 0x00007ffff43fce88 in js::proxy_Call(JSContext*, unsigned int, JS::Value*) () at /usr/lib64/thunderbird/libxul.so #9 0x00007ffff448c0f0 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () at /usr/lib64/thunderbird/libxul.so #10 0x00007ffff449a9c5 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) () at /usr/lib64/thunderbird/libxul.so #11 0x00007ffff462d34e in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) () at /usr/lib64/thunderbird/libxul.so #12 0x00007ffff7fd9cc8 in () .... but that file doesn't exists, thus it tries with libedataserver-1.2.so.18 later and that succeeds. After that other Camel (also from evolution-data-server package) libraries are loaded, but none of them has a dependency on libedataserver, except of the evolution-ews module, which has dependency on libedataserver and many other evolution-related libraries, including also webkitgtk3. All these loads are done within that e_source_registry_new_sync() call. I guess the problem is that thunderbird loads the libedataserver-1.2.so.18 on its own, in a way which doesn't work for loadable modules, thus the dependency on /usr/lib64/evolution-data-server/camel-providers/libcamelews.so loads that libedataserver .so again, but that library doesn't have initialized the type, and it fails to register the type with the runtime warning from comment #0. Loading the shared library twice is just a big no-no here.
I'm moving this to thunderbird-lightning, the internals here are out of my knowledge. Summarizing the steps to reproduce: a) have installed these packages: thunderbird-31.5.0-1 thunderbird-lightning-3.3-5 evolution-ews-3.12.11-1 b) install a thunderbird add-on "EDS Calendar Integration 0.4.1" c) restart thunderbird The thunderbird start fails with runtime warnings as in comment #0. Uninstalling evolution-ews makes this work again. The problem seems to be that thunderbird loads libedataserver-1.2.so.18 on its own, while the libcamelews.so has a runtime dependency on libedataserver-1.2.so, but this is not (in runtime) satisfied by the thunderbird-loaded libedataserver-1.2.so.18, thus it is loaded again, which breaks the GLib type system.
I really don't see any connection to lightning as it doesn't reference libedataserver. Neither does TB directly, but maybe the TB folks have some ideas.
I chose "thunderbird-lightning", because the add-on requires it. Without the lightning, and the add-on installed, the thunderbird works fine.
Without lightning installed addon terminates before calling libedatasource.
Created attachment 1029206 [details] testcase I got the report of such a crash in sflphone in bug #1219435. I've narrowed down the issue to e_source_registry_new_sync being called in a dl-opened library. See attached test case. On F21 with evolution-data-server-3.12.11-2.fc21.x86_64, this testcase produces the following output: $ ./test (process:20168): GLib-GObject-WARNING **: cannot register existing type 'EDBusSource' (process:20168): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed (process:20168): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed (process:20168): GLib-GObject-WARNING **: invalid cast from 'EDBusSourceProxy' to '<invalid>' On Fedora rawhide, the testcase works as expected.
(In reply to Sandro Mani from comment #12) > On Fedora rawhide, the testcase works as expected. The same as in Fedora 22. I suppose a change in GLib, or another underlying library, fixed the module loading when being done with dlopen.
*** Bug 1219435 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.