Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1197848 - libedataserver.so loaded twice
Summary: libedataserver.so loaded twice
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: thunderbird
Version: 21
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Horak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1219435 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-02 18:28 UTC by balbusm
Modified: 2015-12-02 17:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-02 09:38:18 UTC
Type: Bug


Attachments (Terms of Use)
testcase (792 bytes, application/x-xz)
2015-05-24 13:40 UTC, Sandro Mani
no flags Details

Description balbusm 2015-03-02 18:28:09 UTC
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.

Comment 1 balbusm 2015-03-02 18:51:00 UTC
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

Comment 2 Milan Crha 2015-03-03 07:49:01 UTC
(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

Comment 3 balbusm 2015-03-04 12:12:37 UTC
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?

Comment 4 Milan Crha 2015-03-04 13:10:31 UTC
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.

Comment 5 Milan Crha 2015-03-04 13:36:40 UTC
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?

Comment 6 balbusm 2015-03-04 13:48:12 UTC
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?

Comment 7 Milan Crha 2015-03-04 14:24:50 UTC
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.

Comment 8 Milan Crha 2015-03-04 14:34:26 UTC
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.

Comment 9 Orion Poplawski 2015-03-04 15:38:04 UTC
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.

Comment 10 Milan Crha 2015-03-05 10:07:11 UTC
I chose "thunderbird-lightning", because the add-on requires it. Without the lightning, and the add-on installed, the thunderbird works fine.

Comment 11 balbusm 2015-03-05 10:09:57 UTC
Without lightning installed addon terminates before calling libedatasource.

Comment 12 Sandro Mani 2015-05-24 13:40:11 UTC
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.

Comment 13 Milan Crha 2015-05-25 11:03:26 UTC
(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.

Comment 14 Sandro Mani 2015-06-07 09:28:48 UTC
*** Bug 1219435 has been marked as a duplicate of this bug. ***

Comment 15 Fedora End Of Life 2015-11-04 11:33:28 UTC
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.

Comment 16 Fedora End Of Life 2015-12-02 09:38:22 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.