Bug 240853 - hangs when restarting login screen with new chosen language
Summary: hangs when restarting login screen with new chosen language
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
: 246414 307831 (view as bug list)
Depends On:
Blocks: F8Blocker
TreeView+ depends on / blocked
 
Reported: 2007-05-22 12:29 UTC by A S Alam
Modified: 2013-07-03 00:44 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-01 02:12:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 473480 0 None None None Never

Description A S Alam 2007-05-22 12:29:37 UTC
Description of problem:
After changing Language for GDM, it shows message showing "Do you wish to
restart the login screen with chosen Language", Pressing "YES", it showing only
mouse, but GDM 
hanged and not restarted, only after killing it, it start again

Version-Release number of selected component (if applicable):
gdm-2.19.1-1.fc8

How reproducible:
Everytime

Steps to Reproduce:
1. Change Language at GDM login screen
2.it will show screen to restart Login Screen
3. Press "Yes"
  
Actual results:
only Mouse shown, but screen not available back

Expected results:
GDM login screen should be back

Additional info:

Comment 1 Jens Petersen 2007-08-30 03:12:48 UTC
*** Bug 246414 has been marked as a duplicate of this bug. ***

Comment 2 Peng Huang 2007-09-04 08:11:53 UTC
I found gdm is blocked in function call gdm_fdgetc (greeter_fd_in) in slave.c
5598 line. It seems not all of write peers of pipe greeter_fd_in was closed when
shutdown gdmgreeter. So the gdm_fdgetc will be blocked instead of return EOF
immediately. I guess it should close slave_fd_out before call gdm_fdgetc.

Comment 3 Peng Huang 2007-09-19 04:24:44 UTC
This problem has been fixed in HEAD version in upstream.

Comment 4 Ray Strode [halfline] 2007-09-19 14:18:23 UTC
Yup, thanks for the fix Huang!

Comment 5 Jens Petersen 2007-09-20 06:21:29 UTC
Reopening, since we really need to do something for this for F8.

Still see this with gdm-2.20.0-1.fc8.

Comment 6 Peng Huang 2007-09-20 07:10:47 UTC
This bug does exist in upstream's gdm. It is just in our version. I found
gdm-2.19.1-reset-pam.patch causes this problem. What is this patch for?

Comment 7 Ray Strode [halfline] 2007-09-20 12:02:48 UTC
This bug is already fixed in rawhide.  I started to build it right after closing
the bug report, and to my surprise mclasen did too.  he typed faster.

reset-pam is for smartcards.

Comment 8 Jens Petersen 2007-09-21 01:38:41 UTC
Sorry, I'd really like to keep this open until I can no longer reproduce.

It is still happening to me after again updating to the latest rawhide
with gdm-2.20.0-3.fc8.  I will try a fresh install now.

Comment 9 Peng Huang 2007-09-21 02:08:14 UTC
Sorry for the typo in comment #6 . It should be: This bug does not exist in
upstream's gdm. :)

I check the code of latest rawhide. It still has this problem. gdm keep the
output peer of pipe in daemon/slave.c, line 2883 .  It is different from
upstream's version because of one our patch.  Upstream gdm just closes pope2[1].
It cause this bug in our version. If we want to keep the output peer of
pipe(slave_fd_out), we should close it before restart the gdmgreet.

2883:    VE_IGNORE_EINTR (close (pipe1[0]));
2884:    whack_greeter_and_slave_fds ();
2885:
2886:    slave_fd_out = pipe2[1];
         ~~~~~~~~~~~~~~~~~~~~~~~
2887:    greeter_fd_out = pipe1[1];
2888:    greeter_fd_in = pipe2[0];


Comment 10 Ray Strode [halfline] 2007-09-21 02:22:12 UTC
Hmm, well the pipe fd *should* be close on exec, and it should get automatically
closed by g_spawn when running the language dialog.

I'll probably have to reproduce this and investigate more, unless you want to.

It's on the Blocker list, so it won't get forgotton before release.

Comment 11 Matthias Clasen 2007-09-22 03:33:33 UTC
I can confirm that it still hangs

Comment 12 Peng Huang 2007-09-24 02:10:40 UTC
I am analyzing the patch (gdm-2.19.5-reset-pam.patch) that causes this bug. Who
can tell me which bug the patch is for fixing ? I need more information about
this patch.

Comment 13 Ray Strode [halfline] 2007-09-24 03:51:09 UTC
Hi Huang,

It's not fixing a bug, it's a patch that provides the ability to reset an active
pam conversation (required for a RHEL5 feature).



Comment 14 Ray Strode [halfline] 2007-09-26 20:22:41 UTC
*** Bug 307831 has been marked as a duplicate of this bug. ***

Comment 15 Adam Pribyl 2007-09-28 18:11:39 UTC
Still see this with rawhide-20070925 live i386 iso.. adding myself to CC.

Comment 16 Ray Strode [halfline] 2007-09-28 18:19:57 UTC
Adam, should be fixed with this build:

http://koji.fedoraproject.org/koji/buildinfo?buildID=19834

if you want to try it out.

Comment 17 Bill Nottingham 2007-09-28 18:23:40 UTC
That build works for me.

Comment 18 Jens Petersen 2007-10-01 01:56:31 UTC
Thanks, works for me too. :)


Note You need to log in before you can comment on or make changes to this bug.