Created attachment 1875276 [details]
File: backtrace

Created attachment 1875277 [details]
File: core_backtrace

Created attachment 1875278 [details]
File: cpuinfo

Created attachment 1875279 [details]
File: dso_list

Created attachment 1875280 [details]
File: environ

Created attachment 1875281 [details]
File: exploitable

Created attachment 1875282 [details]
File: limits

Created attachment 1875283 [details]
File: maps

Created attachment 1875284 [details]
File: mountinfo

Created attachment 1875286 [details]
File: open_fds

Created attachment 1875287 [details]
File: proc_pid_status

Created attachment 1875288 [details]
File: var_log_messages

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.

Happened again, again when clicking favorite button furiously.

Happened again, this time when picking a profile picture.

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.

Reproducer:
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:
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality

I can reproduce it the same way Kamil has described it.

This is easily reproducible on a VM:
https://bugzilla.redhat.com/show_bug.cgi?id=2079258
https://bugzilla.redhat.com/show_bug.cgi?id=2079284

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

Like lnie, I can reproduce it in a VM, but not on bare metal.

*** Bug 2079284 has been marked as a duplicate of this bug. ***

*** Bug 2079258 has been marked as a duplicate of this bug. ***

That's interesting, I can't reproduce it on bare metal either.

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.

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

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:

https://gitlab.gnome.org/GNOME/gnome-contacts/-/blob/main/src/contacts-store.vala#L37
https://gitlab.gnome.org/GNOME/gnome-contacts/-/blob/main/src/contacts-store.vala#L233
https://gitlab.gnome.org/GNOME/gnome-contacts/-/blob/main/src/contacts-store.vala#L265

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

https://gitlab.gnome.org/GNOME/gnome-contacts/-/blob/main/src/contacts-main-window.vala#L347
https://gitlab.gnome.org/GNOME/gnome-contacts/-/blob/main/src/contacts-contact-pane.vala#L217

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?

Yeah, I think that's it, actually.

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

https://koji.fedoraproject.org/koji/taskinfo?taskID=86313870

Here's the MR:

https://gitlab.gnome.org/GNOME/gnome-contacts/-/merge_requests/185

Adam's build seems to fix this issue. I don't see any new bugs from it.

(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)

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 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

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.

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.
https://meetbot.fedoraproject.org/fedora-meeting/2022-04-28/f36-final-go_no_go-meeting.2022-04-28-17.01.log.html#l-455

This issue has no upstream link. Did you consider reporting a bug upstream?

Well, interestingly enough, I can't trigger the crash anymore. And I had 100% success rate earlier. So I guess something changed...

gnome-contacts-42.0-1.fc36.x86_64
evolution-data-server-3.44.2-1.fc36.x86_64