Bug 239238 - User switcher (Fc7 Gnome) crashes after 3 cycles, forcing reboot
Summary: User switcher (Fc7 Gnome) crashes after 3 cycles, forcing reboot
Alias: None
Product: Fedora
Classification: Fedora
Component: fast-user-switch-applet   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: jmccann
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-06 19:57 UTC by Leslie Satenstein
Modified: 2015-01-14 23:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-03 19:48:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Leslie Satenstein 2007-05-06 19:57:16 UTC
Description of problem:

Summary line is accurate. When problem occurs, doing a restart of X does not
recover. Only way to recover is via a reboot. 

Version-Release number of selected component (if applicable):

Fc7 test4 with all updates as of May 6th, 2007

How reproducible:

Create two or three users on the FC7 not with XEN kernel.  After logging onto
one, switch to the other, logon to it, then switch back. Try this twice.

Steps to Reproduce:
Actual results:

Reboot of system necessary. 

Expected results:

To work as intended

Additional info:

Comment 1 Leslie Satenstein 2007-06-01 21:04:29 UTC
Although I reported it in Fc6 6.93 test4, the problem still is present in fc7
production (non XEN). 

I will advise if the problem is present in the XEN version. 

Whatever, I just wont use that facility.

Comment 2 Leslie Satenstein 2007-10-19 17:39:32 UTC
Here it is just before fc8 release, and the problem persists. Since the initial
posting I have upgraded system as follows:

a) memory 2.5 gig   
b) Mother board intel d945gnt (with most recent bios update)
c) fc7 64bit Gnome interface version
d) all updates (yum update or pup) completed.

The summary information (below) does not change.

If I log to two virtual users (ctl-alt-f1, ctl-alt-f2), and then try to return
to  Gnome (ctl-alt-f7), I will hear the switch (terminal -- NEC Multisync
E1100+) has relay to change but screen remains dark.  Multiple ctl-alt-backspace
does not restore screen.

Only recourse is a reboot.

Comment 3 Leslie Satenstein 2007-11-01 01:09:08 UTC
Here is further information. 

a) problem is with both 32 bit and 64 bit distributions executing from the same pc.

b) Mother board is an intel d945gnt, using built-in video (945 bios driver) 
c) Video resolution 1024 x 768 
d) memory 2.5gigs

Comment 4 Leslie Satenstein 2007-11-01 01:15:17 UTC
With kernel  and ati card, it works. (32bit version of pc).

Will report back to you with Intel System.

Comment 5 Leslie Satenstein 2007-11-01 03:36:52 UTC
Hello Matthias. Here is some results following further testing. The problem has
to do with recursion. 

Following further testing.  Starting from User A.

User A calls User B, who does some work, and then user B exits.
Result: All is OK, One can return to User A.

User A calls User B, who does some work, calls User C. User C exits and returns
to B and then user B exits and it returns to A.  All is OK.

User A calls User B, who does some work, calls User A. User A logs in, even
though he is already logged in. He does some work and exits and then the system
does not allow the return to B.  

The problem is that in Case 3, User A is logged twice when actived the second
time, and it fouls up Gnome. When the screen does not return, I know that the
system prompt is present because I turned on sound to indicate the presence of a
system prompt logon screen. 

Sound returns at the right time, telling me to log, but the screen is black.

What is available when the screen is black is the text logon via ctl-alt-f1..
ctl-alt-f6  ctl-alt-f7 is the black screen.

NB. In Case3, ctl-alt-backspace resets gnome, but does not restore the screen in
the sense of removing the blackout. Logon screen remains blacked out. BUT
ctl-alt-f1 is available to issue a reboot.

I believe that the fix is to have the code check that the user X was not still
previously logged in. If X was previously logged in, generate an error message.
User Y should only be able to return to  User X if he/she exits. 

This checking should only be done when trying to do a switch-user.

Logon recursion is not allowed.

Comment 6 Matthias Clasen 2007-11-01 03:53:54 UTC
Hmm, how do you log in a second time as A ?

The fast-user-switch-applet should already keep track of logged in users, and do
the right thing when you switch to them (bring up the existing session), as
should gdm. 

Comment 7 Leslie Satenstein 2007-11-01 04:14:57 UTC
Log as A, switch user to B, and switch user to A. If I recall, it should not
allow B to switch user to A. Ergo, problems of black screen.  

I did Log as A, switch to B, in B, switch to C, in C log to A.

And it did it.
and it forces reboot, as the screen remains blanked out.

With ctl-alt-f1, I sometimes have the text screen, and sometimes not.

When not, I am able to do logon, (first prompt), and then password.
Followed by reboot. (all in the black).

Comment 8 Matthias Clasen 2007-11-01 13:08:40 UTC
Sorry, I still don't follow. If I repeat your A,B,C sequence, I get back to the
first session at the end, ending up on the screensaver lock dialog. And
everything works just fine.

Unless you mean something different with "log to" as opposed to "switch to" in

Log as A, switch to B, in B, switch to C, in C log to A.

Comment 9 Leslie Satenstein 2007-11-03 23:05:23 UTC
I regret but this problem is with a Intel d945gnt and the i810 driver (video is
on the mother board).  It happens with 32 bit and 64 bit versions of Fedora 7.

I believe the problem is one of X windows not being reset properly. Is it
possible that something is not saved on the stack.  For example, I did not test
the preceding sequence, where, between user A and User B, I do a screen
resolution change. 

Lets try it in 7 days, when fc8 is out and I have fc8 installed.


Comment 10 Leslie Satenstein 2007-11-05 22:25:59 UTC
Here is some feedback. The same problem exists in fc8 test3. And I have more

If one never touches compiz or beryl, then there is no corruption of files in
one of the hidden subdirectories directories of the user directory ~

I took three logons that did not include my existing user id, and I could not
make the problem occur.

Right now, I have a home directory that I will clean of personal stuff, and I
will forward it.

FWI. The problem also occurs with two other distributions.  UBUNTU, and
PClinuxOS.  The problem is truly with compiz and / or beryl.

Advise if I need to send you my stripped down home directory.


Comment 11 Leslie Satenstein 2008-02-06 03:05:30 UTC
Well, Today, Feb 5, 2008, with kernel I tried several
iterations to a depth of 4. 
Everything worked (gnome-->gnome)  5 cycles
(gnome->gnome->kde)   2 cycles

No lockup and also X windows did not die. 

Therefore, for the X64 non-zen version of fedora and version 8, everything works.

Later, I will report the same experiment using Fedora 7 X64 Non Zen version,
using the same hardware as last reported.

Comment 12 Leslie Satenstein 2008-02-08 16:36:47 UTC
Did the Fedora 7 tests, with all users not on compiz, and no recursion.
After two levels, of nesting  (logon leslie --> logon Laurie --> Logon guest01)
The system failed. (black screen of death).
The ctl-alt-sequences of f1 to f7 or backspace) could not restore the system.
I tried usb plugging and unplugging, got some error messages, but... no luck

The messages included lost page, and dead device.

On reboot, since I could not recover logon screen, the file system indicated
orphan entries. Never-the-less, the forced reboot brought the system back to normal.

This problem, bottom line, is that it still exists in Fed7_X64 non-zen, but does
not exist with Fed8_x64


Comment 13 jmccann 2008-04-03 19:48:30 UTC
Closing as fixed in current release per last comment.  Thanks.

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