After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794626 - cannot open gnome settings anymore after to close its window with "users" selected
cannot open gnome settings anymore after to close its window with "users" sel...
Status: RESOLVED DUPLICATE of bug 791703
Product: gnome-control-center
Classification: Core
Component: User Accounts
3.28.x
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-03-23 15:03 UTC by Strangiato
Modified: 2018-03-24 16:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Strangiato 2018-03-23 15:03:14 UTC 
Gnome 3.28 on Arch Linux
Since Gnome 3.28, active panel is remembered when gnome settings is closed, I closed gnome settings when users panel was active and now I can not open Gnome settings anymore.
Terminal shows an error about timeout reached.
Comment 1 Benjamin Berg 2018-03-23 21:12:32 UTC 
Could you please attach the output? While you are at it, you can also try to get a backtrace from the process by using gdb.

i.e.:
$ gdb --args gnome-control-center user-accounts
(gdb) run
...
(gdb) threads apply all

Or whatever works for you.
Comment 2 Strangiato 2018-03-23 21:48:14 UTC 
output is nothing beyond "Failed to register: timeout was reached"

gnome settings opens when I run your gdb command.

maybe a problem related to cheese?
cheese does not find my webcam since update to Gnome 3.28.
In Gnome 3.26.2 cheese also gave me "timeout was reached" error.
See bug 791703.
Comment 3 Benjamin Berg 2018-03-23 22:31:12 UTC 
Sounds plausible that this is actually a duplicate of bug 791703. The user account panel uses cheese to create user photos.
Comment 4 Strangiato 2018-03-24 00:17:10 UTC 
now gdb command shows these errors

Failed to register: timeout was reached
[Thread 0x7fffc9eab700 (LWP 21279) exited]
[Thread 0x7fffca6ac700 (LWP 21278) exited]
[Thread 0x7fffcaead700 (LWP 21277) exited]
[Thread 0x7fffcbc57700 (LWP 21276) exited]
[Inferior 1 (process 21272) exited with code 01]

"thread apply all bt" shows nothing
Comment 5 Benjamin Berg 2018-03-24 12:23:30 UTC 
Those are not errors. It just tells you that 4 threads exited and the application quit with exit code 1 (which to be honest might be interesting).

Anyway, the problem is that gnome-control-center is still running, but it is not responding over dbus.

Can you check whether there is any other process, e.g. with:
$ ps aux |grep gnome-control-center

If you find one, run "gdb -p PID" (PID is the first number printed by "ps aux" after the username, then hit Ctrl+C and do "threads apply all bt" again.
Comment 6 Benjamin Berg 2018-03-24 12:32:42 UTC 
By the way. I was only able to come to the above conclusion because I had the exact error message. The full "Failed to register: timeout was reached" string was essential to understand what is going on.

Another thing that is only now obvious to me is that you closed g-c-c just before. i.e. if you log out or reboot then the issue will be gone again.
Comment 7 Strangiato 2018-03-24 13:47:13 UTC 



+
Trace
    238506






Thread 1
          (Thread 0x7f7545c81100 (LWP 2825))


    

  • 
#0
pthread_cond_wait

    • 

  • 
#1
pw_thread_loop_wait

    • 

  • 
#2
0x00007f751027f426 in

    • 

  • 
#3
gst_device_provider_start

    • 

  • 
#4
gst_device_monitor_start

    • 

  • 
#5
0x00007f754294469c in

    • 

  • 
#6
g_initable_new_valist

    • 

  • 
#7
g_initable_new

    • 

  • 
#8
um_photo_dialog_new

    • 

  • 
#9
0x0000563512f5b5be in

    • 

  • 
#10
g_type_create_instance

    • 

  • 
#11
0x00007f754551f6d9 in

    • 

  • 
#12
g_object_new_valist

    • 

  • 
#13
g_object_new

    • 

  • 
#14
0x0000563512ebc2bf in

    • 

  • 
#15
g_cclosure_marshal_VOID__STRINGv

    • 

  • 
#16
0x00007f7545519e76 in

    • 

  • 
#17
g_signal_emit_valist

    • 

  • 
#18
g_signal_emit

    • 

  • 
#19
0x0000563512ebab09 in

    • 

  • 
#20
g_closure_invoke

    • 

  • 
#21
0x00007f754552dbb0 in

    • 

  • 
#22
g_signal_emit_valist

    • 

  • 
#23
g_signal_emit

    • 

  • 
#24
0x00007f7545519e76 in

    • 

  • 
#25
g_signal_emit_valist

    • 

  • 
#26
g_signal_emit_by_name

    • 

  • 
#27
0x0000563512ebb62e in

    • 

  • 
#28
g_type_create_instance

    • 

  • 
#29
0x00007f754551f6d9 in

    • 

  • 
#30
g_object_new_valist

    • 

  • 
#31
g_object_new

    • 

  • 
#32
cc_window_new

    • 

  • 
#33
0x0000563512eb5354 in

    • 

  • 
#34
g_closure_invoke

    • 

  • 
#35
0x00007f754552dc88 in

    • 

  • 
#36
g_signal_emit_valist

    • 

  • 
#37
g_signal_emit

    • 

  • 
#38
g_application_register

    • 

  • 
#39
0x00007f7545807700 in

    • 

  • 
#40
g_application_run

    • 

  • 
#41
main

    • 













Comment 8


Benjamin Berg





          2018-03-24 16:47:56 UTC
        



This is a duplicate of bug #791703. Either a cheese bug itself or an issue in the stack further down (specifically gstreamer or pipewire).

*** This bug has been marked as a duplicate of bug 791703 ***