Screen lock unlocks after 5 wrong attempts

I have no been able to reproduce this. I do see the password prompt dialog vanish after the fifth failure, but it does not unlock. Further typing re-prompts with the password entry dialog. Are you seeing any crashes being reported?

I did not wait for the screen saver to lock. I manually locked the
desktop on all these occasions. Did you notice I am using karmic?

On Thu, 2009-10-08 at 17:26 +0000, Kees Cook wrote:
> I have no been able to reproduce this. I do see the password prompt
> dialog vanish after the fifth failure, but it does not unlock. Further
> typing re-prompts with the password entry dialog. Are you seeing any
> crashes being reported?
>
> ** Package changed: nautilus (Ubuntu) => gnome-screensaver (Ubuntu)
>
> ** Changed in: gnome-screensaver (Ubuntu)
> Status: New => Incomplete
>

I manually locked as well (gnome-screensaver-command -l). Yes, Karmic (it was reported in your headers: DistroRelease: Ubuntu 9.10).

I really do not know which additional information I can send you, but I
can consistently reproduce this behavior with 5 wrong attempts; even
while leaving the password field blank.

R.

On Thu, 2009-10-08 at 18:42 +0000, Kees Cook wrote:
> I manually locked as well (gnome-screensaver-command -l). Yes, Karmic
> (it was reported in your headers: DistroRelease: Ubuntu 9.10).
>

Can people seeing this issue read through https://wiki.ubuntu.com/DebuggingProgramCrash and http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions#head-d50bc17e7d6f3a51c4715f02c657195e80e26c2c and try gather debug output? Also, running "strace -fp $(pidof gnome-screensaver)" might show some clues as well.

Attached: gnome-screensaver debug output.

I can't seem to get a backtrace (it just says "No stack"). Note that triggering the bug sometimes takes a few tries, and on one occasion, the correct password wouldn't be accepted anymore. Also, had one instance that, after failing to input the correct password several times, the screen just went black (mouse pointer visible and moveable though)

Attached: strace output.

I can confirm this too

could people having the issue give details on their videocard, videodrivers and what they do to get the crash (use empty password, type quickling or not, etc)

to get a stacktrace you need to:

- install libgtk2.0-0-dbg
- run gdb gnome-screensaver with no one running before
(gdb) break gdk_x_error
(gdb) run --sync
get the crash
(gdb) bt full

run --sync --no-daemon

chrisccoulson got a trace here: http://paste.ubuntu.com/293307/

Like Kees Cook, after five attempts, the login dialog goes away, but doesn't unlock. However, if I persist in using the wrong password, it does in fact unlock.

An interesting fact: afterwards, I'm no longer able to lock the screen using alt+ctrl+L. (Which I was the first time)

Happens for me too on my ThinkPad T60p with a Mobility FireGL V5200 graphics device.

Graphics driver: radeon
Kernel: 2.6.31-14-generic #46-Ubuntu SMP Tue Oct 13 16:47:28 UTC 2009 x86_64 GNU/Linux

Trying to lock the screen after the first time just gives me the error «** Message: Screensaver is not running!»

You can't lock it again because gnome-screensaver is crashing

I was able to lock the screen again after just running "gnome-screensaver" without any arguments.

The bug appeared again, and this time I got the output from the command "gnome-screensaver-command -l":

> The program 'gnome-screensaver' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
> (Details: serial 1551 error_code 9 request_code 53 minor_code 0)
> (Note to programmers: normally, X errors are reported asynchronously;
> that is, you will receive the error a while after causing it.
> To debug your program, run it with the --sync command line
> option to change this behavior. You can then get a meaningful
> backtrace from your debugger if you break on the gdk_x_error() function.)

I see this happening on an Intel and an ATI/AMD machine:
- Toshiba laptop, Intel GM45, xserver-xorg-video-intel driver (2:2.9.0-1ubuntu2).
- Gigabyte GA-MA785GM-US2H with ATI HD4200, xserver-xorg-video-radeon driver.

There doesn't seem to be any clear pattern to triggering the bug: sometimes it happens after 5 tries, sometimes after 40. Fast/normal/slow typing and the number or type of characters used for input don't seem to matter. I've seen the bug trigger about 30 times now, which is hardly enough to be able to say anything definite however.

Attached: laptop info + backtrace. (Nothing additional about the ATI machine I'm afraid, because all the debug-packages completely filled the root partition. Bleh.)

Thanks everyone. I think Chris Coulson is digging into this -- it seems like some kind of race between the password dialog shutting itself down every 5th attempt and the main gnome-screensaver process trying to kill it. Or something is causing a pixmap to get displayed after it has been removed (maybe during the dialog shake animation?)

This seems to be because gnome-screensaver-dialog exits after the 5th failed attempt, whilst the main gnome-screensaver process is still shaking the dialog to indicate an auth failure. I've ran it through xtrace which shows that gnome-screensaver tries to do some X calls on the gnome-screensaver-dialog window after it was destroyed. I also rebuilt gnome-screensaver with some extra debug statements which show that gnome-screensaver-dialog exits whilst the dialog is being shaken. This happens every time, but it just seems to be that you need to be unlucky with the timing to get it to crash.

Anyway, the current implementation is not robust and is race-prone, so I will work on fixing that now.

This bug was fixed in the package gnome-screensaver - 2.28.0-0ubuntu2

---------------
gnome-screensaver (2.28.0-0ubuntu2) karmic; urgency=low

  * debian/patches/08_gs_dialog_request_to_exit.patch:
    - Don't let the dialog process exit on its own accord when the
      password is entered incorrectly 5 times. Instead, request that
      the main gnome-screensaver process terminates it when ready. This
      avoids a race where the dialog process exits during the middle
      of the auth-failure animation, leading to unhandled X errors
      (LP: #446395)

 -- Chris Coulson <email address hidden> Fri, 16 Oct 2009 01:32:07 +0100

Please do not change the status of fix-released bugs.

I can confirm this "bug" on gnome-screensaver 2.28.0-0ubuntu3.

However I can reproduce this bug with 1 wrong password attempt.

Maybe it's related to this bug but it's a different one.

If you can trigger it with one wrong password attempt, then it's not the same bug

This bug still exists in version 2.28.0-0ubuntu3.3, architecture: amd64
I can reproduce the bug, sometimes at the first attempt.

See my last comment. If you're experiencing an issue on the first attempt, then it is not the same bug. This issue was specific to the dialog closing during the shake animation, which only happens after the 5th attempt