Bug 1486763 - [abrt] Crash under signal_cb() at gdbusobjectmanagerclient.c:995
Summary: [abrt] Crash under signal_cb() at gdbusobjectmanagerclient.c:995
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: 26
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:fe24b82428551bb80ed821e8c92...
: 1489650 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-30 13:50 UTC by Jan Kalina
Modified: 2018-05-29 11:29 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 11:29:45 UTC
Type: ---


Attachments (Terms of Use)
File: backtrace (94.49 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: cgroup (386 bytes, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: core_backtrace (61.25 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: cpuinfo (1.36 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: dso_list (20.05 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: environ (1.42 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: limits (1.29 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: maps (92.25 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: open_fds (1.40 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: proc_pid_status (1.27 KB, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details
File: var_log_messages (28 bytes, text/plain)
2017-08-30 13:50 UTC, Jan Kalina
no flags Details

Description Jan Kalina 2017-08-30 13:50:06 UTC
Description of problem:
adding kerberos account into online accounts

Version-Release number of selected component:
evolution-data-server-3.24.5-1.fc26

Additional info:
reporter:       libreport-2.9.1
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-source-registry
crash_function: g_hash_table_lookup_node
executable:     /usr/libexec/evolution-source-registry
journald_cursor: s=dbf33b58580e4150a8b20889ebfabb27;i=9edc;b=ca92a977cbef4b1784ea2aa4ff8ac1a6;m=3f0b2bb6a;t=557f8baaa1e47;x=9b404301b55f3f68
kernel:         4.12.8-300.fc26.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Potential duplicate: bug 1272252

Comment 1 Jan Kalina 2017-08-30 13:50:17 UTC
Created attachment 1320080 [details]
File: backtrace

Comment 2 Jan Kalina 2017-08-30 13:50:19 UTC
Created attachment 1320081 [details]
File: cgroup

Comment 3 Jan Kalina 2017-08-30 13:50:21 UTC
Created attachment 1320082 [details]
File: core_backtrace

Comment 4 Jan Kalina 2017-08-30 13:50:23 UTC
Created attachment 1320083 [details]
File: cpuinfo

Comment 5 Jan Kalina 2017-08-30 13:50:25 UTC
Created attachment 1320084 [details]
File: dso_list

Comment 6 Jan Kalina 2017-08-30 13:50:27 UTC
Created attachment 1320085 [details]
File: environ

Comment 7 Jan Kalina 2017-08-30 13:50:28 UTC
Created attachment 1320086 [details]
File: limits

Comment 8 Jan Kalina 2017-08-30 13:50:31 UTC
Created attachment 1320087 [details]
File: maps

Comment 9 Jan Kalina 2017-08-30 13:50:32 UTC
Created attachment 1320088 [details]
File: open_fds

Comment 10 Jan Kalina 2017-08-30 13:50:34 UTC
Created attachment 1320089 [details]
File: proc_pid_status

Comment 11 Jan Kalina 2017-08-30 13:50:36 UTC
Created attachment 1320090 [details]
File: var_log_messages

Comment 12 Milan Crha 2017-08-31 07:17:40 UTC
Thanks for a bug report. I see from the backtrace that evolution-source-registry received a property change through D-Bus related to GOA account, while most of the other threads had been stuck (waiting for processing) in goa_client_new_sync() call.

The thing is that this crashed in gio/GDBus code, somewhere in glib2, which evolution has no control of, thus I'm moving this to glib2 for further investigation.

Comment 13 Milan Crha 2017-09-08 06:43:44 UTC
*** Bug 1489650 has been marked as a duplicate of this bug. ***

Comment 14 Milan Crha 2017-09-08 06:47:01 UTC
Out of interest, what configured GOA account types are shown in Settings->Online Accounts for you, please? I have there one nextCloud account and one Google, the nextCloud has all options enabled, while the Google account only mail, contacts and calendar, all the rest is disabled. I do not have any other accounts configured there.

Comment 15 Jan Kalina 2017-09-08 07:00:01 UTC
Sorry, dont remember exactly, but I think it was two Google accounts (sync of all) and Facebook account and while adding kerberos account, it crashed.
But unable to reproduce the crash now.

Comment 16 Milan Crha 2017-09-08 07:55:23 UTC
Jan's backtrace shows property change notification for account:
   /org/gnome/OnlineAccounts/Accounts/account_1504024844_0
Does
   ~/.config/goa-1.0/accounts.conf
contain that account (account_1504024844_0)? If it does, what is the Provider key there, please?

Similarly for Matthew, where it's account_1499893425_1.

I do not know the internals of GOA, but it looks like that the goa-daemon decided to notify about some changes for some account, in Matthew's case just after login, which evolution-source-registry noticed too, due to the GoaObject being involved, which may, eventually, be the forgotten signal handler from. But it's only a wild guess.

Comment 18 Debarshi Ray 2017-09-11 12:15:46 UTC
Looking at attachment 1320080 [details], it seems that threads 3 to 9 are all trying to synchronously create a GoaClient instance. Would it be possible to create one instance and share it across the whole process? That might make it easier to track thing like these because we'd be dealing with the state of one GoaClient object instead of many.

Comment 19 Debarshi Ray 2017-09-11 13:04:19 UTC
Every GoaClient has a GDBusObjectManagerClient.

Looking at thread #1 in attachment 1320080 [details], it seems that GDBusObjectManagerClient::signal_cb is being invoked with an invalid GDBusObjectManagerClient object (ie. user_data/manager). That's the only way for the GHashTable to be invalid. However, I don't see any CRITICALs in the session logs from a failed cast.

g_dbus_connection_signal_subscribe keeps track of the thread-default GMainContext at the time of its invocation, so that the callback (ie. signal_cb) is invoked on the same context. In this case, signal_cb is crashing from thread #1. So, does e-d-s have another GoaClient that's on thread #1?

Comment 20 Milan Crha 2017-09-11 14:05:49 UTC
(In reply to Debarshi Ray from comment #19)
> I don't see any CRITICALs in the session logs from a failed cast.

I noticed it's pretty common that the log doesn't contain the most recent claims. It can be something about flushing disk buffers before ABRT copies the file, but it's only my personal guess. Or there is something about user session and root access to those files, I do not recall precisely, there just heard something about it from ABRT developers in the semi-distant past.

> g_dbus_connection_signal_subscribe keeps track of the thread-default
> GMainContext at the time of its invocation, so that the callback (ie.
> signal_cb) is invoked on the same context. In this case, signal_cb is
> crashing from thread #1. So, does e-d-s have another GoaClient that's on
> thread #1?

As far as I can tell, it's only the e_goa_password_based_lookup_sync() calling goa_client_new_sync(). While the backtrace shows that it's always the same EGoaPasswordBased object, it doesn't share the GoaClient object, it creates it on demand and then frees it immediately afterwards. Looking into the backtrace of Thread 3 and in those related functions, none of them sets thread default main context, thus the GDBus uses the main context from the main() thread, as expected. 

It can also mean that the problem is in GDBus, no? Looking into gdbusobjectmanagerclient.c, they unsubscribe from the signal in finalize(), not in dispose(), which might be better.

By the way, do you think the way evolution-data-server code is written regarding the password-based GOA object is conceptually wrong? I think I can change it, maybe even for cases when the GOA daemon dies, but I'm afraid it would just hide the issue, wherever it is.

Comment 21 Milan Crha 2017-09-19 09:08:01 UTC
I made some changes on the evolution-data-server side [1] to reuse the GoaClient object when possible. It does not necessarily fix this particular crash, but I guess it'll make things less evil. The change is for 3.27.1+ and 3.26.1+.

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=ba290665f

Comment 22 Fedora End Of Life 2018-05-03 08:04:30 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. 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 '26'.

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 26 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 23 Fedora End Of Life 2018-05-29 11:29:45 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
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.