Bug 2079228 - [abrt] gnome-contacts: folks_individual_get_personas(): gnome-contacts killed by SIGSEGV
Summary: [abrt] gnome-contacts: folks_individual_get_personas(): gnome-contacts killed...
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-contacts
Version: 36
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:48a3f226047bd206b67d35d0bb8...
: 2079258 2079284 (view as bug list)
Depends On:
Blocks: F36FinalFreezeException
TreeView+ depends on / blocked
Reported: 2022-04-27 08:50 UTC by Kamil Páral
Modified: 2022-06-06 12:41 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-06-06 12:41:22 UTC
Type: ---

Attachments (Terms of Use)
File: backtrace (95.72 KB, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: core_backtrace (32.41 KB, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: cpuinfo (2.32 KB, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: dso_list (221 bytes, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: environ (1.18 KB, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: exploitable (82 bytes, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: limits (1.29 KB, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: maps (3.96 KB, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: mountinfo (2.71 KB, text/plain)
2022-04-27 08:50 UTC, Kamil Páral
no flags Details
File: open_fds (2.30 KB, text/plain)
2022-04-27 08:51 UTC, Kamil Páral
no flags Details
File: proc_pid_status (1.39 KB, text/plain)
2022-04-27 08:51 UTC, Kamil Páral
no flags Details
File: var_log_messages (1.43 KB, text/plain)
2022-04-27 08:51 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2022-04-27 08:50:41 UTC
Description of problem:
I think this particular crash happened when I marked a contact as favorite and then immediately unfavorited it. But that crash was not repeatable. However, I saw gnome-contacts crash very often doing seemingly random operations, not sure if all boil down to this particular root cause, or they are different.

//Edit: See comment 16 for a good reproducer.

Version-Release number of selected component:

Additional info:
reporter:       libreport-2.17.1
backtrace_rating: 3
cgroup:         0::/user.slice/user-1000.slice/user/app.slice/dbus-:1.2-org.gnome.Contacts
cmdline:        /usr/bin/gnome-contacts --gapplication-service
crash_function: folks_individual_get_personas
executable:     /usr/bin/gnome-contacts
journald_cursor: s=31ef534050564d3898b9cbb35f72d66c;i=a07;b=5ea6af8cce104e18bc62ef2d978693f4;m=b181393;t=5dd9e8ed0d4a6;x=eb584086ac47e24c
kernel:         5.17.3-302.fc36.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 folks_individual_get_personas
 #1 contacts_avatar_find_display_name at src/gnome-contacts.p/contacts-avatar.c:499
 #2 contacts_avatar_construct at src/gnome-contacts.p/contacts-avatar.c:185
 #3 contacts_avatar_new at src/gnome-contacts.p/contacts-avatar.c:219
 #4 contacts_contact_sheet_create_header at src/gnome-contacts.p/contacts-contact-sheet.c:725
 #5 contacts_contact_sheet_update at src/gnome-contacts.p/contacts-contact-sheet.c:616
 #7 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3743
 #10 __lambda14_ at src/libcontacts.a.p/contacts-store.c:1167
 #11 ___lambda14__gsource_func at src/libcontacts.a.p/contacts-store.c:1176
 #15 g_main_context_iterate.constprop.0 at ../glib/gmain.c:4211

Comment 1 Kamil Páral 2022-04-27 08:50:45 UTC
Created attachment 1875276 [details]
File: backtrace

Comment 2 Kamil Páral 2022-04-27 08:50:46 UTC
Created attachment 1875277 [details]
File: core_backtrace

Comment 3 Kamil Páral 2022-04-27 08:50:48 UTC
Created attachment 1875278 [details]
File: cpuinfo

Comment 4 Kamil Páral 2022-04-27 08:50:49 UTC
Created attachment 1875279 [details]
File: dso_list

Comment 5 Kamil Páral 2022-04-27 08:50:51 UTC
Created attachment 1875280 [details]
File: environ

Comment 6 Kamil Páral 2022-04-27 08:50:52 UTC
Created attachment 1875281 [details]
File: exploitable

Comment 7 Kamil Páral 2022-04-27 08:50:53 UTC
Created attachment 1875282 [details]
File: limits

Comment 8 Kamil Páral 2022-04-27 08:50:55 UTC
Created attachment 1875283 [details]
File: maps

Comment 9 Kamil Páral 2022-04-27 08:50:56 UTC
Created attachment 1875284 [details]
File: mountinfo

Comment 10 Kamil Páral 2022-04-27 08:51:00 UTC
Created attachment 1875286 [details]
File: open_fds

Comment 11 Kamil Páral 2022-04-27 08:51:01 UTC
Created attachment 1875287 [details]
File: proc_pid_status

Comment 12 Kamil Páral 2022-04-27 08:51:03 UTC
Created attachment 1875288 [details]
File: var_log_messages

Comment 13 Kamil Páral 2022-04-27 09:03:22 UTC
Happened again, this time probably when right clicking a contact in the list to select it (non-repeatable). ABRT incremented the crash count for this reported bug, so probably the same traceback.

Comment 14 Kamil Páral 2022-04-27 09:07:54 UTC
Happened again, again when clicking favorite button furiously.

Comment 15 Kamil Páral 2022-04-27 09:10:19 UTC
Happened again, this time when picking a profile picture.

Comment 16 Kamil Páral 2022-04-27 09:40:53 UTC
OK, this seems to be depending on time rather than actions. I can very reliably reproduce this, if I add a new contact in the first ~25 seconds after gnome-contacts start. At the 25 second mark, gnome-contacts crashes.

1. start gnome-contacts and immediately create a new contact (the contact *must* have an email address to trigger the bug).
2. In ~25 seconds after the app was started, the app crashes

Proposing as a Final blocker as violating the basic functionality criterion:

Comment 17 Lukas Ruzicka 2022-04-27 09:55:58 UTC
I can reproduce it the same way Kamil has described it.

Comment 18 lnie 2022-04-27 12:20:51 UTC
This is easily reproducible on a VM:

but I can not reproduce it on a bare metal machine,no matter how hard I try.

Comment 19 Ben Cotton 2022-04-27 12:52:23 UTC
Like lnie, I can reproduce it in a VM, but not on bare metal.

Comment 20 Kamil Páral 2022-04-27 12:56:21 UTC
*** Bug 2079284 has been marked as a duplicate of this bug. ***

Comment 21 Kamil Páral 2022-04-27 12:56:27 UTC
*** Bug 2079258 has been marked as a duplicate of this bug. ***

Comment 22 Kamil Páral 2022-04-27 13:14:32 UTC
That's interesting, I can't reproduce it on bare metal either.

Comment 23 Adam Williamson 2022-04-27 15:50:51 UTC
Note, lili's tracebacks are not the same as each other, or the same as Kamil's. All three run through contacts_avatar_new , but then differ after that; Kamil's and one of Lili's wind up in different bits of libfolks, Lili's other one winds up in libgee.

They may well still be the same bug, and indicate contacts_avatar_new doing something sketchy, but the fact that we get different tracebacks each time seems significant.

Comment 24 Adam Williamson 2022-04-27 16:41:44 UTC
I can reproduce this in a VM too. If I run gnome-contacts from a console, when the crash happens, these messages appear:

* (gnome-contacts:3005): CRITICAL **: 12:41:11.152: gee_iterable_iterator: assertion 'self != NULL' failed

** (gnome-contacts:3005): CRITICAL **: 12:41:11.152: gee_iterator_next: assertion 'self != NULL' failed

** (gnome-contacts:3005): CRITICAL **: 12:41:11.152: gee_iterable_iterator: assertion 'self != NULL' failed

** (gnome-contacts:3005): CRITICAL **: 12:41:11.153: gee_iterator_next: assertion 'self != NULL' failed

** (gnome-contacts:3005): CRITICAL **: 12:41:11.153: gee_iterable_iterator: assertion 'self != NULL' failed

** (gnome-contacts:3005): CRITICAL **: 12:41:11.153: gee_iterator_next: assertion 'self != NULL' failed

(gnome-contacts:3005): GLib-GObject-CRITICAL **: 12:41:11.154: g_type_interface_peek: assertion 'instance_class != NULL' failed

Comment 25 Adam Williamson 2022-04-27 16:57:09 UTC
Poking through the code a bit, the 'contact store' has this concept of a 'quiescent' state, and various things are written to wait for the store to be in that state before happening:


However, it doesn't look to me like the "new contact" code does that:


etc. etc. - following the whole chain of "create a new contact" code as best as I can from main-window to contact-pane, I don't see anywhere that checks the contact store is 'quiescent' before it tries to create or edit a contact in it.

So, could that be the problem here? The store has an initialization phase that we should wait out before trying to change things in it, but we're not?

Comment 26 Adam Williamson 2022-04-27 17:52:15 UTC
Yeah, I think that's it, actually.

Can folks try this scratch build? Seems to resolve the issue for me.


Here's the MR:


Comment 27 Ben Cotton 2022-04-27 18:25:45 UTC
Adam's build seems to fix this issue. I don't see any new bugs from it.

Comment 28 Kamil Páral 2022-04-27 20:11:38 UTC
(In reply to Adam Williamson from comment #26)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=86313870

This doesn't seem to work well for me:
a) The first time I started gnome-contacts and clicked + to add a new contact, it got stuck in a 100% cpu loop and I had to kill it (that never happened before, and I didn't see it afterwards either).
b) When I add a new contact, the contact doesn't appear in the contact list on the left. I see it's details in the right pane, but not in the list on the left. After some timeout (I assume those ~25 seconds after app start), it appears. But it's confusing.
c) When I do b) but start selecting other contacts in the list instead of waiting for the timer, the app crashes once the timer expires. ABRT ignores it because it's not an official build and I didn't have time to create a proper traceback, but the journal contains:

#0  0x00007fda3f07410d folks_individual_get_personas (libfolks.so.26 + 0x3010d)
#1  0x000055a82ed900ac contacts_avatar_construct (gnome-contacts + 0x200ac)
#2  0x000055a82ed9ba16 contacts_contact_sheet_update (gnome-contacts + 0x2ba16)
#3  0x00007fda3ef2ada0 g_closure_invoke (libgobject-2.0.so.0 + 0x13da0)
#4  0x00007fda3ef574b6 signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x404>
#5  0x00007fda3ef47a0e g_signal_emit_valist (libgobject-2.0.so.0 + 0x30a0e)
#6  0x00007fda3ef47c93 g_signal_emit (libgobject-2.0.so.0 + 0x30c93)
#7  0x000055a82edabe77 ___lambda14__gsource_func (gnome-contacts + 0x3be77)
#8  0x00007fda3ee2c46b g_idle_dispatch (libglib-2.0.so.0 + 0x5146b)
#9  0x00007fda3ee2ff4f g_main_context_dispatch (libglib-2.0.so.0 + 0x54f4f)
#10 0x00007fda3ee85168 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa>
#11 0x00007fda3ee2d8e0 g_main_context_iteration (libglib-2.0.so.0 + 0x528e0)
#12 0x00007fda3ebdb27d g_application_run (libgio-2.0.so.0 + 0xe027d)
#13 0x000055a82ed8be36 main (gnome-contacts + 0x1be36)
#14 0x00007fda3dd54590 __libc_start_call_main (libc.so.6 + 0x2d590)
#15 0x00007fda3dd54649 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2d649)
#16 0x000055a82ed8be75 _start (gnome-contacts + 0x1be75)

Comment 29 Adam Williamson 2022-04-27 23:20:20 UTC
b) is what's supposed to happen. The problem is that the "store" contacts uses is still initializing itself at this point. My patch tells contacts to wait for that to be done before it actually writes the contact to the store. However, while it's waiting to do that, it shows you a sort of "dummy" view of the contact on the right hand side - it's actually a sort of temporary instance of the contact, the way this whole thing works is it creates a temporary contact for the purpose of doing the edits, then ultimately clones it into the store and deletes the temporary instance. So the right-hand side view can show you the details from the temporary instance, but the left-hand side view is based on what's actually in the store, so it won't show the new contact till it's actually written there.

I could move the 'wait for the store to be initialized' code up a bit before the display of the 'temporary' contact details, but if I do that I'm not sure what will be shown on the right hand side. We could try it out though, I guess.

c) doesn't entirely surprise me unfortunately :| I did kinda suspect something like that might happen. It may be the case that this needs some kind of 'block the UI with a spinner till the write is done' deal, or just make the add/edit buttons inactive on app start until the store is initialized.

Comment 30 Niels De Graef 2022-04-28 13:01:52 UTC
Comment 25 is spot on with the analysis. 

I made a branch recently to deal with some related issues. Unfortunately, it was going to add a few strings (which means breaking i18n string freeze). I'll see if I can cook up something tomorrow morning that's based on that work

Comment 31 Niels De Graef 2022-04-28 13:02:42 UTC
FWIW, I'm not entirely sure if this is a regression in GNOME 42, but I don't have time until tomorrow morning to check this out.

Comment 32 Ben Cotton 2022-04-28 19:20:21 UTC
In today's Go/No-Go meeting, we agreed to accept this as a freeze exception and reject it as a blocker. This falls outside of "basic functionality", but is worth fixing if possible.

Comment 33 Michael Catanzaro 2022-06-06 12:24:08 UTC
This issue has no upstream link. Did you consider reporting a bug upstream?

Comment 34 Kamil Páral 2022-06-06 12:41:22 UTC
Well, interestingly enough, I can't trigger the crash anymore. And I had 100% success rate earlier. So I guess something changed...


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