The test fails because the following assertion in tp_connection_upgrade_contacts is not satisfied: n_contacts >= 1. Backtrace: #0 0x0000003eb1e352d5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000003eb1e36beb in __GI_abort () at abort.c:93 #2 0x0000003f3a84b5ee in g_logv (log_domain=0x7fb4c7e590a2 "tp-glib", log_level=<optimized out>, format= 0x3f3a8b6710 "%s: assertion `%s' failed", args1=0x7fff9364c5b8) at gmessages.c:557 #3 0x0000003f3a84b682 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:577 #4 0x00007fb4c7deb1e9 in tp_connection_upgrade_contacts (self= 0x17b4000 [TpConnection], n_contacts=0, contacts=0x0, n_features=0, features=<optimized out>, callback= 0x7fb4c7da6910 <contacts_queue_item_upgraded_cb>, user_data=0x17b6540, destroy=0, weak_object=0x17c44c0 [TpChannel]) at contact.c:4222 #5 0x00007fb4c7da6751 in process_contacts_queue (self=0x17c44c0 [TpChannel]) at channel-contacts.c:378 #6 0x00007fb4c7da7ae8 in _tp_channel_contacts_members_changed (self= 0x17c44c0 [TpChannel], added=0x17c70c0, removed=0x17b64a0, local_pending=<optimized out>, remote_pending=0x17b6560, actor=<optimized out>, details=0x17bf770 = {...}) at channel-contacts.c:660 #7 0x00007fb4c7da9f91 in tp_channel_group_members_changed_detailed_cb (self= 0x17c44c0 [TpChannel], added=0x17c70c0, removed=0x17b64a0, local_pending= 0x17b67a0, remote_pending=0x17b6560, details=0x17bf770 = {...}, unused= 0x0, weak_obj=0x0) at channel-group.c:1208 #8 0x00007fb4c7d846b1 in _tp_cli_channel_interface_group_invoke_callback_for_members_changed_detailed (tpproxy=0x17c44c0 [TpChannel], error=<optimized out>, args=0x17c6f00, generic_callback= 0x7fb4c7da9eb0 <tp_channel_group_members_changed_detailed_cb>, user_data=<optimized out>, weak_object=<optimized out>) at _gen/tp-cli-channel-body.h:3173 #9 0x00007fb4c7e3279c in tp_proxy_signal_invocation_run (p=0x17b6700) at proxy-signals.c:266 #10 0x0000003f3a8427ed in g_main_dispatch (context=0x1798760) at gmain.c:2441 #11 g_main_context_dispatch (context=0x1798760) at gmain.c:3014 #12 0x0000003f3a842fc8 in g_main_context_iterate (context=0x1798760, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3092 #13 0x0000003f3a84360d in g_main_loop_run (loop=0x17c0b10) at gmain.c:3300 #14 0x0000000000409022 in tp_tests_connection_run_request_contact_handle ( connection=0x17c0b10, id=0x17b4000 "@!{\001") at util.c:152 #15 0x00000000017b1ed0 in ?? () #16 0x0000000000000000 in ?? ()
Created attachment 52170 [details] [review] channel-contacts: guard against no-op updates process_contacts_queue() can already cope with ContactsQueueItems in the queue which do not actually have any contacts to prepare. As a comment in the function describes, we still go through the motions of enqueuing a preparation/upgrade operation to avoid reordering events. However, previously the function assumed that if any of the three arrays (of contact objects, ids, or handles) were non-NULL, then they would be non-empty. This assumption is false, as <https://bugs.freedesktop.org/show_bug.cgi?id=41470> illustrates. The concrete example in that bug is an emission of MembersChanged, with all arrays except Removed empty, and Actor set to 0. We don't bother preparing contacts which are removed; so _tp_channel_contacts_queue_prepare_async() is called with an empty array of contacts. There are a few other signals which can lead to this situation. So this patch makes process_contacts_queue() do the right thing if the arrays are present but empty. (Previously all three paths would assert in this situation.) Fixes: <https://bugs.freedesktop.org/show_bug.cgi?id=41470>
Here's a fix.
r+
Thanks, merged, will be in a release shortly.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.