GNOME Bugzilla – Bug 352818
the dialog is not always shown
Last modified: 2006-10-02 18:18:59 UTC
Please describe the problem: the latest stable version doesn't always show the dialog when needed, meaning that the daemon needs to be killed. Here's a part of the debug-log: [check_for_clock_skew] gs-watcher-x11.c:1327 (17:52:44): checking wall clock for hibernation, changed: 0:00:01 [_gs_watcher_notice_activity] gs-watcher-x11.c:569 (17:52:45): Activity detected: resetting timers [remove_idle_timer] gs-watcher-x11.c:464 (17:52:45): killing idle_timer (600000, 29314) [add_idle_timer] gs-watcher-x11.c:477 (17:52:45): starting idle_timer (590000, 29315) [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1407 (17:52:45): Idle 0 seconds [check_for_clock_skew] gs-watcher-x11.c:1327 (17:52:45): checking wall clock for hibernation, changed: 0:00:01 [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1407 (17:52:46): Idle 1 seconds [check_for_clock_skew] gs-watcher-x11.c:1327 (17:52:46): checking wall clock for hibernation, changed: 0:00:01 [_gs_watcher_notice_activity] gs-watcher-x11.c:569 (17:52:46): Activity detected: resetting timers [remove_idle_timer] gs-watcher-x11.c:464 (17:52:46): killing idle_timer (600000, 29315) [add_idle_timer] gs-watcher-x11.c:477 (17:52:46): starting idle_timer (590000, 29316) [gs_manager_set_lock_active] gs-manager.c:363 (17:52:46): Setting lock active: 1 [gs_grab_get_keyboard] gs-grab-x11.c:166 (17:52:46): Grabbing keyboard widget=119 [gs_grab_get_mouse] gs-grab-x11.c:192 (17:52:46): Grabbing mouse widget=119 [gs_manager_activate] gs-manager.c:1320 (17:52:46): fading out [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1407 (17:52:47): Idle 0 seconds [check_for_clock_skew] gs-watcher-x11.c:1327 (17:52:47): checking wall clock for hibernation, changed: 0:00:01 [fade_done_cb] gs-manager.c:1276 (17:52:47): fade completed, showing windows[window_map_cb] gs-manager.c:1036 (17:52:47): Handling window map event [gs_window_clear] gs-window-x11.c:255 (17:52:47): Clearing window [clear_all_children] gs-window-x11.c:230 (17:52:47): Clearing all child windows [window_show_cb] gs-manager.c:1088 (17:52:47): Handling window show [gs_watcher_set_active] gs-watcher-x11.c:774 (17:52:47): turning watcher: OFF [remove_idle_timer] gs-watcher-x11.c:464 (17:52:47): killing idle_timer (600000, 29316) [_gs_watcher_set_active_internal] gs-watcher-x11.c:757 (17:52:47): Stopping idle watcher [gs_listener_send_signal_active_changed] gs-listener-dbus.c:165 (17:52:47): Sending the ActiveChanged(TRUE) signal on the session bus [gs_window_xevent] gs-window-x11.c:463 (17:52:47): not raising our windows[window_map_event_cb] gs-manager.c:1023 (17:52:47): Handling window map_event event [xorg_lock_smasher_set_active] gs-grab-x11.c:109 (17:52:47): Disabling the x.org grab smasher [xorg_lock_smasher_set_active] gs-grab-x11.c:128 (17:52:47): XF86MiscSetGrabKeysState(off) returned MiscExtGrabStateSuccess [gs_grab_move_keyboard] gs-grab-x11.c:328 (17:52:47): Moving keyboard grab from 119 to 2200209 [gs_grab_move_keyboard] gs-grab-x11.c:335 (17:52:47): *** doing X server grab[gs_grab_release_keyboard] gs-grab-x11.c:218 (17:52:47): Ungrabbing keyboard [gs_grab_get_keyboard] gs-grab-x11.c:166 (17:52:47): Grabbing keyboard widget=2200209 [gs_grab_move_keyboard] gs-grab-x11.c:357 (17:52:47): *** releasing X server grab [gs_grab_move_mouse] gs-grab-x11.c:274 (17:52:47): Moving pointer grab from 119 to 2200209 [gs_grab_move_mouse] gs-grab-x11.c:281 (17:52:47): *** doing X server grab[gs_grab_release_mouse] gs-grab-x11.c:236 (17:52:47): Ungrabbing pointer [gs_grab_get_mouse] gs-grab-x11.c:192 (17:52:47): Grabbing mouse widget=2200209 [gs_grab_move_mouse] gs-grab-x11.c:304 (17:52:47): *** releasing X server grab [manager_maybe_start_job_for_window] gs-manager.c:202 (17:52:47): Not starting job because dialog is up [gs_window_xevent] gs-window-x11.c:463 (17:52:47): not raising our windows[window_map_event_cb] gs-manager.c:1023 (17:52:47): Handling window map_event event [xorg_lock_smasher_set_active] gs-grab-x11.c:109 (17:52:47): Disabling the x.org grab smasher [xorg_lock_smasher_set_active] gs-grab-x11.c:128 (17:52:47): XF86MiscSetGrabKeysState(off) returned MiscExtGrabStateAlready [gs_grab_move_keyboard] gs-grab-x11.c:321 (17:52:47): Window 2200209 is already grabbed, skipping [gs_grab_move_mouse] gs-grab-x11.c:262 (17:52:47): Window 2200209 is already grabbed, skipping [manager_maybe_start_job_for_window] gs-manager.c:202 (17:52:47): Not starting job because dialog is up [unfade_idle] gs-manager.c:995 (17:52:47): resetting fade [gs_fade_reset] gs-fade.c:640 (17:52:47): Resetting fade [gs_manager_request_unlock] gs-manager.c:1406 (09:32:57): Request unlock but dialog is already up [gs_manager_request_unlock] gs-manager.c:1406 (09:32:57): Request unlock but dialog is already up [gs_manager_request_unlock] gs-manager.c:1406 (09:32:57): Request unlock but dialog is already up [gs_manager_request_unlock] gs-manager.c:1406 (09:32:57): Request unlock but dialog is already up and so on. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I'm not able to reproduce this with 2-14 or HEAD. Does this happen every time you lock the screen? Can you try to pinpoint when it does happen? What distro and version of g-s are you running? The conspicuous thing about the log you've posted is that there is no "Handling dialog up" message. This may mean that the dialog_up flag is stuck on TRUE when it shouldn't be. I think that this must mean that window_dialog_down_cb was not run previously. That is strange. I guess in any case we should reset the dialog_up flag when we deactivate.
I've commited a change to 2-14 and HEAD to reset the dialog_up flag when deactivating as a safeguard for when dialog-down isn't handled. Can you try one of these versions from CVS and see if it has any effect? Thanks.
this is ubuntu dapper, g-s version 2.14.3-0ubuntu1. It doesn't happen every time, which makes it strange. This is happening for at least three admins here. We are all using ldap+kerberos and NFSv4 mounts, but the tickets are not expired so a "missing" home-directory is not to blame. I'll try to get someone test this without kerberos-secured mounts. ..and I'll try the change next week ;) Could you post the patch itself so I can apply it on top of the package?
http://cvs.gnome.org/viewcvs/gnome-screensaver/src/gs-manager.c?r1=1.63&r2=1.64
it seems to work better, I haven't seen the issue anymore on computers that have the patched version.
That's good. It is still worth trying to understand why this is happening. Can you try to pinpoint when it occurs? Can you post a complete debug log when it does? Thanks.
...on an unpatched system obviously :) And also a debug log from a patched system after a while (long enough that you think the problem would have occurred) would be useful too in order to look for why or when the dialog-down doesn't fire or get handled.
Created attachment 71888 [details] debug log from failure it was maybe the fifth time I locked the screen when the dialog failed to come up, this is with an unpatched g-s.
one important (?) note. When the failure occurs, the screensaver is not started (=there's no activity on the screen). This made me think that a specific saver was broken, but I tried them all and they all worked. After this previous failure I tried it again (lock the screen, press a button, wait for dialog, enter the password ...) but after ~30 tries I couldn't repeat it. It's still happening every now and then.
I'll let the screensaver run over the weekend, surely it should then have failed to bring up the dialog.. the debug log follows then.
Created attachment 72245 [details] debug log with the patch, gzipped forgot to direct the output to a file, so this is the log from yesterday to this morning.
Oh, we'll consider this fixed then.