Segmentation Fault in GNOME Control Center When Managing Flatpak Permissions (Fedora 40, GNOME 46)

I am encountering a segmentation fault in gnome-control-center when attempting to manage the “Background” permission for certain Flatpak applications. This issue has occurred consistently with at least two different applications: Viber and Pulsar.

System Information:

  • OS: Fedora 40 (x86_64)
  • GNOME Version: 46.3
  • Flatpak Version: 1.14.4
  • Flatseal Version: 1.8.3
  • gnome-control-center Version: 46.3-1.fc40

The segmentation fault happens when the permissions are modified through either GNOME Control Center or Flatseal. Interestingly, GNOME Control Center does not crash when the settings are at odds:

Steps to Reproduce:

  1. Open Flatseal and navigate to either the Viber or Pulsar Flatpak application.
  2. Change the state of Background option under Portals. Note that once it has been change it has to be “unset”. Changing it back manually does not help.
  3. Open GNOME Control Center and try to navigate to the AppsViber or Pulsar. permissions for Viber or Pulsar.
  4. GNOME Control Center crashes consistently.
  5. Note that this works both ways. If you reset the settings from Flatseal and change the background settings from GNOME settings, next time you open it and try to navigate there, GNOME settings starts crashing again. The only way to fix that is is to open Flatseal and reset the setting from there.

Relevant Logs:

journalctl -xe | grep gnome-control-center:

Aug 26 18:18:47 192.168.1.5 audit[197887]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=197887 comm="gnome-control-c" exe="/usr/bin/gnome-control-center" sig=11 res=1
Aug 26 18:18:47 192.168.1.5 kernel: gnome-control-c[197887]: segfault at 0 ip 00005652dcd3d2da sp 00007fff815ca8c0 error 4 in gnome-control-center[802da,5652dcd0c000+159000] likely on CPU 1 (core 1, socket 0)
                                                      Module gnome-control-center from rpm gnome-control-center-46.3-1.fc40.x86_64
                                                      #0  0x00005652dcd3d2da row_activated_cb.lto_priv.1 (gnome-control-center + 0x802da)
                                                      #34 0x00005652dcd31740 main (gnome-control-center + 0x74740)
                                                      #37 0x00005652dcd318d5 _start (gnome-control-center + 0x748d5)
Aug 26 18:18:48 192.168.1.5 abrt-server[197998]: Package 'gnome-control-center' isn't signed with proper key

gdb gnome-control-center :

Thread 1 "gnome-control-c" received signal SIGSEGV, Segmentation fault.
0x00005555555d42da in get_background_allowed (self=0x5555568a8b10, 
    app_id=0x5555579b2d60 "dev.pulsar_edit.Pulsar", set=0x7fffffffc5a0, 
    allowed=0x7fffffffc5a4)
    at ../panels/applications/cc-applications-panel.c:479
479	  *allowed = perms == NULL || strcmp (perms[0], "no") != 0;

Additional Note: I’ve noticed that the logs consistently include the message: Package 'gnome-control-center' isn't signed with proper key. I want to clarify that I’m using the official Fedora Workstation, and I haven’t made any intentional changes or modifications to the GNOME Control Center package. The package was installed and updated through the standard Fedora repositories.

This merits a bug report on the upstream issue tracker. You’ll need to attach a stack trace, which you can get following these instructions.

Huh, that’s odd. I wonder what’s going on there. Probably an ABRT bug?

2 Likes

Thanks for the quick reply @catanzaro. I believe this issue might be related specifically to Fedora/RHEL. I’ve noticed a significant number of similar problems reported on the Red Hat Bugzilla, while there are only a few such reports on GNOME Control Center’s issue tracker.

Would it be more appropriate to post this on Red Hat Bugzilla instead?

EDIT: This was not reproducible on Arch (Manjaro) as far as I can recall.

No. It will probably be ignored if you report it there. Red Hat Bugzilla is good when you want to interact with the Fedora packager rather than the upstream developer.

There it is:

Seems the issue is in my system as per the linked bug report. This topic can now be closed. Thanks again.