GNOME session freezes to black screen, Failsafe GNOME session works fine

Thank you for taking the time to report this bug and helping to make Ubuntu better. Does it works fine if you log in with another new created user?

I created another user and tried to log in to the "GNOME" session with that user. That worked. However, if I try to log out with that other user, the system freezes (similar to what I experienced with my normal user, as I described previously), and it displays the desktop wallpaper with GNONE's empty taskbars, only the mouse is moveable and it doesn't respond to keyboard input. I had to hit the reset button of my system. However, unlike my normal user, I can still log in tot the "GNOME" session with the other user after the crash on logout (it doesn't crash to a black screen if I log in with the other user).

If I try to log in to the "Failsafe GNOME" session with the other user, it does not freeze when I log out.

I forgot to change the status from incomplete to new after giving the required extra information, so I'm doing that now.

Is your loopback network interface correctly configured? Does "ping localhost" work correctly?

Yes, "ping localhost" works:

alexander@alexander-desktop:~$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.025 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.025 ms

And my network/internet connection also works, most of the time. Sometimes after I log in to the "Failsafe GNOME" session, I notice that my network connection is not working. Then I simply right-click the NetworkManager applet and uncheck "Enable Networking" and then check it again, then NetworkManager establishes a working connection again.

And I don't now if it's useful in any way, but I attached the .xsession-errors file, which was located as a hidden file in my home directory, it gives some error messages.

Thanks for your comments. This does not appear to be a bug report as such. We appreciate the difficulties you are facing, but it would make more sense to raise your question in the support tracker. http://launchpad.net/support

Thank you for your reply, but could you please go into more details instead of giving a standard answer? I don't understand, if this freezing at login is not intended behavior how can it not be a bug?

The bug tracker is about clearly describing issues to get them fixed. What you are doing is asking for help getting your system working again, you should use the support tracker for that, they will help you to figure what is wrong and when you have figured what is creating the issue you can open a bug on the right package with extra informations

I had the idea that I was describing this bug as clearly as possible to get it fixed as a consequence, and that getting it fixed would help me getting my system working again. To be clear, I certainly was trying to write a bugreport, not a help request. Writing a good bugreport was my intention, and if the bug could be fixed and I'd have a correctly functioning system again that would be a good thing, but not the goal of this bugreport. Are you implying that I did not describe the bug properly (not "clearly" enough, as you emphasized)?

Besides that, you still haven't explained why you don't accept this bugreport. Could you please tell me why this is not a valid bug? Is my description not correct or is information missing? Is the bug fixed already, is it a duplicate? I believe that I have described the steps necessary to reproduce the bug, described the effects of the bug, and that the effects of the bug are not normal behavior. Am I missing something here?

you didn't describe a sequence of action leading to the bug on an another computer or included a debugging information or what code logic is wrong so it's not really possible for somebody else to work on the issue without those details

"debugging information on what code logic is wrong" rather

Hmm, ok. I did not know how to provide debugging information for this bug because the crash happens when I log in. I have used GDB in the past to provide backtraces, but AFAIK there is no way to start GDB or something like that to get a backtrace before I log in, or is there? I've read the information on the wiki for debugging procedures - https://wiki.ubuntu.com/DebuggingProcedures - the document which describes my situation most closely there is probably - https://help.ubuntu.com/community/DebuggingSystemCrash - but that only deals with reproducing crashes on a text console, which is probably not what I need to do if my crash happens when I log in to GNOME.

To be honestly I don't know how to provide the correct debugging information then, there is no info on the Ubuntu wiki either. The only way I could think of was providing some log files, I thought the .xsession-errors file was useful?

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/125902

In my case, disabling composite options work fine.
Please apply this solution

> Hmm, ok. I did not know how to provide debugging information for this bug because the crash happens when I log in.

that's why you should use the support tracker, they will help you to figure what is wrong and then you can open a bug with detailled informations

nainu, thank you for your comment. Disabling the "desktop effects" and disabling "AddARGBGLXVisuals" (not sure if both are necessary or just disabling desktop effects is enough) in my xorg.conf allowed me to log in normally to the "GNOME" session.

The xsession-errors file which I attached also lists an error message for Compiz. Have we verified that this is a bug caused by X.org/Compiz not playing nice with gnome-session and can I mark this bug as a duplicate of bug #125902? Or do you still want me to ask the question in the support tracker, Sebastien?

Currently, as of 22 September, with the latest updates this problem doesn't seem to occur anymore. I can have Compiz enabled and use session saving at the same time without any crashes when logging in to the default session. So I guess the updates fixed it.