Could it be related to this bug https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2459 ?

CC: (none) => geiger.david68210

If yes, is rygel package installed?

David, thanks for jumping in on this. Inevitably assigning to you.

I have just tried (x64) gnome-control-center under LxQt, and nothing happens! Will try later under Gnome.

Source RPM: (none) => gnome-control-center-44.1-1.mga9.src.rpm
CC: geiger.david68210 => (none)
Assignee: bugsquad => geiger.david68210

Lewis, this is specific to i586.

no rygel packages installed

also, it seems a multi DE install masks the issue.

one of *those* failures.

(In reply to David GEIGER from comment #1)
> Could it be related to this bug
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2459 ?

yes, this is, with except that report OP does not specify 32/64 bit.
a later comment indicates 32bit

So please install rygel to see what's happen, normally it should fix the segfault.

# urpmi rygel
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release (distrib1)")
  libges-gir1.0                  1.22.0       1.mga9        i586    
  libges1.0_0                    1.22.0       1.mga9        i586    
  libgupnp-dlna-gst2.0_4         0.12.0       4.mga9        i586    
  libgupnp-dlna-gstreamer        0.12.0       4.mga9        i586    
  librygel2.8_0                  0.42.3       1.mga9        i586    
  rygel                          0.42.3       1.mga9        i586    
5.9MB of additional disk space will be used.
1.5MB of packages will be retrieved.
Proceed with the installation of the 6 packages? (Y/n) 

---------------------------------------------------------------------------------
$ gnome-control-center mouse
Segmentation fault (core dumped)

relevant output from journalctl -b:

May 12 15:43:17 localhost kernel: multiqueue1:src[4096]: segfault at 1 ip b7f3fb1b sp 959e6c18 error 4 in libgobject-2.0.so.0.7600.2[b7f2d000+33000] likely on CPU 0 (core 0, socket 0)
May 12 15:43:17 localhost kernel: Code: 44 24 04 c7 40 04 00 00 00 00 c3 8d 74 26 00 8b 44 24 04 8b 40 04 c3 8d b4 26 00 00 00 00 90 53 8b 44 24 08 8b 58 04 8b 48 10 <0f> be 03 84 c0 74 1a 8d b6 00 00 00 00 89 ca 83 c3 01 c1 e2 05 29

I'm wondering if this is an issue of similar to sse2 support and compiler
flags.

What's the output of the flags line for one of the cpus listed in /proc/cpuinfo?

Adding Thomas to the cc list.

CC: (none) => davidwhodgins, tmb

(In reply to Dave Hodgins from comment #11)
> I'm wondering if this is an issue of similar to sse2 support and compiler
> flags.
> 
> What's the output of the flags line for one of the cpus listed in
> /proc/cpuinfo?
> 
> Adding Thomas to the cc list.

all cpus so far have been either x86_64 capable

or Virtualbox 64bit cpu

the issue is repeatable on real h/w or virtual h/w

will post some cpu info later

not sure if this is what (In reply to Dave Hodgins from comment #11)
> I'm wondering if this is an issue of similar to sse2 support and compiler
> flags.
> 
> What's the output of the flags line for one of the cpus listed in
> /proc/cpuinfo?
> 
> Adding Thomas to the cc list.

not sure if this is what you requested:

lscpu
Architecture:            i686
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         36 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  BIOS Vendor ID:        Intel(R) Corporation
  Model name:            Intel(R) Core(TM) i3 CPU       M 350  @ 2.27GHz
    BIOS Model name:     Intel(R) Core(TM) i3 CPU       M 350  @ 2.27GHz  CPU @ 
                         2.2GHz
    BIOS CPU family:     206
    CPU family:          6
    Model:               37
    Thread(s) per core:  2
    Core(s) per socket:  2
    Socket(s):           1
    Stepping:            2
    CPU(s) scaling MHz:  55%
    CPU max MHz:         2266.0000
    CPU min MHz:         933.0000
    BogoMIPS:            4521.51
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc
                         a cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht 
                         tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts 
                         xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monit
                         or ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_
                         2 popcnt lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vn
                         mi flexpriority ept vpid dtherm arat flush_l1d

The bug is in gstreamer. I downloaded one of the gnome-control-center animations:

  https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/mouse-and-touchpad/assets/scroll-natural-l.webm

and got the same segfault when executing this command:

  gst-play-1.0 scroll-natural-l.webm

However this command:

  gst-launch-1.0 filesrc location=scroll-natural-l.webm ! matroskademux ! vp9dec ! autovideosink

plays the animation without any problem, so it seems likely this is a bug in the base gstreamer package and not in the plugins.

Source RPM: gnome-control-center-44.1-1.mga9.src.rpm => gstreamer???
CC: (none) => mageia

Looking at Martin's detective work (and where on earth did you dig up the second command?!):

 $ urpmq --requires-recursive gnome-control-center | grep gstreamer
gstreamer1.0-libav
gstreamer1.0-plugins-bad
gstreamer1.0-plugins-base
gstreamer1.0-plugins-good
gstreamer1.0-plugins-ugly
gstreamer1.0-soup
gstreamer1.0-tools
lib64gstreamer-plugins-base-gir1.0
lib64gstreamer-plugins-base1.0_0
lib64gstreamer1.0_0
lib64gupnp-dlna-gstreamer

 $ urpmq --requires-recursive mate-notification-daemon | grep gstreamer
gstreamer1.0-tools
lib64gstreamer-plugins-base1.0_0
lib64gstreamer1.0_0

No sign of the base gstreamer pkg, but the last three in common at least.
-------------------------------------------------------------------------
DavidG wonders whether this bug is the same as bug 31928, but there are differences:
* Ben thinks this bug is 32-bit only (comment 4, comment 7), Martin does not say. The newer bug is presumed x64.
* Ben says this bug only happens with a Gnome-only installation (comment 6). Martin does not say. The newer bug is for Mate, not yet known whether that also has Gnome. But the desktops have much in common.

I only see this bug in a 32-bit install. I see the same fault in a Mate-only install. Oddly the gst-launch command doesn't work there, but nor does it work in a GNOME on Xorg session. That looks to be a different problem, and may just be a gstreamer usage issue.

On investigation, the gst-play-1.0 command comes from the gstreamer1.0-plugins-base package.

Thanks for those clarifications:
- 32-bit        [so perhaps comment 11 re sse2 ?]
- single desktop

On a multi-desktop setup, x64, under Gnome, the fault does *not* happen.
Same system, Mate, 'gnome-control-center' just exits immediately! See nothing in the journal.

Keywords: (none) => FOR_ERRATA9

still valid:

ISO Name: Mageia-9-rc1-i586.iso
DATE.txt: Mon Jul  3 06:29:42 PM CEST 2023

https://wiki.mageia.org/en/Mageia_9_Errata#GNOME

Keywords: FOR_ERRATA9 => IN_ERRATA9
CC: (none) => fri

valid for Mga10 cauldron