Created attachment 188377 [details]
Xorg.log

Anything in ~/.xsession-errors ?

According to guy in this thread is started:
https://bbs.archlinux.org/viewtopic.php?id=119060
there is nothing in ~/.xsession-errors.

I will check on my machine when it freezes again and post that file here.

I just had a crash. See attachment for .xsession-errors.

Created attachment 188412 [details]
xsession-errors

> ** (gnome-shell:3767): WARNING **: Accessibility: org.a11y.atspi schema not found. Are you sure that at-spi or at-spi2 is installed on your system?

gsettings aborts the process if it can't find all the schemas. You need to install at-spi.

I have at-spi 1.32.0-4 installed.

Try installing at-spi2.

Ok, in my repo I have:

extra/at-spi 1.32.0-4 [installed]
    Assistive Technology Service Provider Interface
extra/at-spi2-atk 2.0.1-1 (gnome) [installed]
    A GTK+ module that bridges ATK to D-Bus at-spi
extra/at-spi2-core 2.0.1-1 (gnome) [installed]
    Protocol definitions and daemon for D-Bus at-spi


As you can see I have now installed all three of them. Do I still need the 1.32 version and do I need both core and atk from the version 2 ?

Above mentioned warning is now gone from my .xsession-errors file. I will test and report back whether this has solved my problems.

Can you check whether $(prefix)/share/glib-2.0/schemas/org.a11y.atspi.gschema.xml exists? How do you start the Shell? What does this command say:
gsettings get org.a11y.atspi atk-bridge-location

Your problem may simply be that GSettings schemas are not loaded correctly, and at-spi is the first schema that the Shell tries to load.

I do have file /usr/share/glib-2.0/schemas/org.a11y.atspi.gschema.xml


I do start shell using GDM and GDM is started with inittab:
x:5:respawn:/usr/sbin/gdm -nodaemon


Using your command:
raqua@Phenom64:/etc-gnome3 
$ gsettings get org.a11y.atspi atk-bridge-location
'/usr/lib/gtk-3.0/modules/libatk-bridge.so'

So everything looks good. My question about how you start the Shell was more: do you run it from packages? If not, then jhbuild can explain why GSettings are not properly found by the Shell.

I am not sure if I understand what do you mean. I installed gnome from my distribution packages. 

Btw. It is still crashing. 

I am uploading new .xsession-errors file.

Created attachment 188424 [details]
xsession-errors part II

And this appeared in my dmesg:
 at-spi-bus-laun[10244]: segfault at 968 ip 00007f2192102a21 sp 00007fff93705e40 error 4 in libX11.so.6.3.0[7f21920de000+139000]

But right after freeze, this was not in logs, it appeared later.

Still freezing in Gnome 3.0.2

(In reply to comment #16)
> Still freezing in Gnome 3.0.2

Just wanted to add that I have been having the exact same issue as Martin.  My work around for the freezing is fallback mode for now..

Hi guys I have same problem. So I ssh from my netbook and I've made little investigation. 

I take a look on any logs (Xorg/dmesg/xsession-errors/messages) and didn't found anything suspicious. 

I've tried to restart daemons, but that brought no effect.
Interesting on the freeze is, that all what happens is that windows manager doesn't respond to keyboard/mouse. So I can move with mouse and see result, but click is without effect. Or I've triyed alt+F2, r, ENTER (restart gnome) but again nothing has happened. Moreover, when it freezes with video on background I could still listen the sound.

Interesting was that when I tried to kill firefox and empathy with -9, they stayed alive as defunct. Then I strace-d gnome-shell instance and it was frozen on call: restart_syscall(<... resuming interupted call ...>)

Please take a look at it, I hope I helped you a bit ;)
Joe

I would say that this bug already deserves to be marked as confirmed.

Since you have SSH access, could you get backtraces for the Shell, and possibly X.org? See https://live.gnome.org/GnomeShell/Debugging.

Martin: Usually, we never mark bugs as confirmed, even when developers know that's a real issue and have information about it. This doesn't prevent them from begin fixed.

Created attachment 189356 [details]
script(https://live.gnome.org/GnomeShell/Debugging) output

Created attachment 189357 [details]
gdb output

Is everyone here using the free radeon driver? Please post your graphics chip's model as well as the mesa version you're using.

Martin:
From your X log it seems you're using the classic r300 driver. Can you try the r300g (gallium) driver instead?

I'm having what sounds like the same problem. From time to time, the Shell just freezes, mouse moves (although the pointer doesn't change as normal over various elements, it just stays on whatever it was when the freeze started). After a couple of minutes, suddenly everything is back to normal, and it even reacts to clicks made during the freeze, changing window focus/stacking appropriately for example.

During one of two such freezes today, I switched out to another virtual console (that still works fine), logged in and had a look at top. gnome-shell was chewing between 95% and 100% CPU continuously until the freeze went away. I straced it and it was spinning around the same system call - sched_yield() or something like that (I'd not seen it before, so the spelling hasn't stuck very firmly in my mind and I've now lost that bit of console history).

I am *not* using the radeon driver. Here's my system:

Fedora 15 x86_64, no additional package sources, up to date (GNOME 3.0.2)
Lenovo ThinkPad T61p, 4GB RAM, Core 2 Duo CPU
nVidia Quadro 140M graphics chip
nouveau 3D driver, Fedora's default setup upon installation of 15
Using GNOME Shell as my primary session. Because the freeze always resolves, I can put up with it for the time being, but obviously I'd like to see it fixed!

The only stuff in my .xsession-errors seems to be various hideous things going on with Firefox plugins. I'll check it just after a freeze next time.

I have ATI x1400 and I'm using xf86-video-ati and Galium on ATI RV515

I have ATI x1400 and I'm ati-dri(mesa) 7.10.2-2

(In reply to comment #25)
> I have ATI x1400 and I'm using xf86-video-ati and Galium on ATI RV515

Ok, that's good. Your gdb trace above is missing debug symbols though. Can you install the debug packages for (at least) your mesa and clutter packages and get that gdb backtrace again please? Thanks.

I have an ATI Radeon X1550 and am using package xf86-video-ati-dri from AUR and ati-dri(mesa) v 7.10.2-2 from Arch's repo's. I have also tried the xf86-video-ati from extra with the same results.

Graphics list out as Gallium 0.4 on ATI RV515 here also.

Created attachment 189579 [details]
PID 10397

I SSH'd in as well and ran gdb against the gnome-shell.  Strangely enough... every time I attached to the running gnome-shell instance it crashed immediately where normally I can run for about an hour or so before it freezes.  Then again I may be doing something wrong.  

Anyway, my output looks about the same as Jozef because I also could not find any debug packages for mesa and/or clutter for my distro.  I ran a package Query looking for anything titled mesa-debug etc.  Again, this is under Arch.  Any suggestions so that I may provide a more useful debug for you?

(In reply to comment #29)
> Anyway, my output looks about the same as Jozef because I also could not find
> any debug packages for mesa and/or clutter for my distro.  I ran a package
> Query looking for anything titled mesa-debug etc.  Again, this is under Arch. 
> Any suggestions so that I may provide a more useful debug for you?

https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces

I seem to be having the same problem, however it only occurs occasionally when my screen turns on after having turned off automatically. When moving the pointer with mouse or touchpad to turn the screen on, my desktop appears but nothing responds except the pointer. The only other thing of note is that the speech bubble beside my user name in the panel has three dots through it. I can switch to other VTs without issue.

System:
Arch Linux x86_64
MacBook4,1
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller
xf86-video-intel 2.15.0-2
mesa 7.10.2-2
intel-dri 7.10.2-2
at-spi 1.32.0-4
at-spi2-atk 2.0.2-1
at-spi2-core 2.0.2-1

"/usr/share/glib-2.0/schemas/org.a11y.atspi.gschema.xml" exists.

Output of "gsettings get org.a11y.atspi atk-bridge-location" is:
"'/usr/lib/gtk-3.0/modules/libatk-bridge.so'"

I have been having several power related issues (battery charge indication incorrect; action on laptop lid close stopped working). Could this issue also be power related?

I shall post logs if they would be helpful after the next occurrence of this bug. Which logs should I post?

my... pacman -Syu says I'm still running testing version of graphics drivers, so maybe switching to 'mormal' would help? What about you guys?

warning: ati-dri: local (7.10.99.git20110429-1) is newer than extra (7.10.2-2)
warning: libgl: local (7.10.99.git20110429-1) is newer than extra (7.10.2-2)
warning: mesa: local (7.10.99.git20110429-1) is newer than extra (7.10.2-2)

(In reply to comment #32)
> my... pacman -Syu says I'm still running testing version of graphics drivers,
> so maybe switching to 'mormal' would help? What about you guys?
> 
> warning: ati-dri: local (7.10.99.git20110429-1) is newer than extra (7.10.2-2)
> warning: libgl: local (7.10.99.git20110429-1) is newer than extra (7.10.2-2)
> warning: mesa: local (7.10.99.git20110429-1) is newer than extra (7.10.2-2)

I'm running the versions from extra.

Created attachment 189833 [details]
PID 16495 

> https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces

Thanks for the link.  If you need the debug info for the rest of the ?? shown let me know.

Hope this helps.

(In reply to comment #22)
> Created an attachment (id=189357) [details]
> gdb output


> Your gdb trace above is missing debug symbols though. Can you
> install the debug packages for (at least) your mesa and clutter packages and
> get that gdb backtrace again please? Thanks.


Jozef:  I had trouble finding the PKGBUILDS at first...  I linked a few of yours if you need them to make w/ symbols.


https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces


$ pacman -Qo /usr/lib/libclutter-glx-1.0.so.0 
/usr/lib/libclutter-glx-1.0.so.0 is owned by clutter 1.6.14-1
http://projects.archlinux.org/svntogit/packages.git/tree/clutter/trunk/

$ pacman -Qo /usr/lib/libGL.so.1
/usr/lib/libGL.so.1 is owned by libgl 7.10.2-2
http://projects.archlinux.org/svntogit/packages.git/tree/mesa/trunk/

$ pacman -Qo /usr/lib/libglib-2.0.so.0
/usr/lib/libglib-2.0.so.0 is owned by glib2 2.28.8-1
http://projects.archlinux.org/svntogit/packages.git/tree/glib2/trunk/

$ pacman -Qo /usr/lib/libxcb.so.1
/usr/lib/libxcb.so.1 is owned by libxcb 1.7-2
http://projects.archlinux.org/svntogit/packages.git/tree/libxcb/trunk/

(In reply to comment #34)
> Created an attachment (id=189833) [details]
> PID 16495 

So, you've SSH in and attached gdb to gnome-shell, right? Was it already frozen when you attached? Also, the output of gjs_dumpstack() goes into your ~/.xsession-errors so we also need that file.

This backtrace here doesn't have anything interesting unfortunately. Please install the debug symbols for mutter and gnome-shell too, just in case.

Does 

grep file ~/.local/share/recently-used.xbel 

show any files that are especially large images?  If so, may be a dupe of bug 650690

(In reply to comment #37)
> Does 
> 
> grep file ~/.local/share/recently-used.xbel 
> 
> show any files that are especially large images?  If so, may be a dupe of bug
> 650690

My "~/.local/share/recently-used.xbel" sometimes references large (>100MB) FLV files. Ahem. Could this be related? I shall check the contents of "recently-used.xbel" upon the next occurrence of this bug.

I got the same problem using stock Arch 64bit and now using 32bit + intel GMA 965 (the only aur pkg is shell-extensions from git) but got problems before installing the git versions too.

Happens very often, 3-5 times a day, i'll try to debug to see if show something. I can go to terminal, but can't log in, can't open htop or any other program, it just show nothing like it's openning forever... if the terminal is already open I can write but no effect if hit enter... weird, and logs don't shows erros apparently.

Tried XFCE w/ compiz and no problems in 2 days of usage.

I tried latest ubuntu, fedora, opensuse and arch (both 64 and 32) with ATI Radeon X2300 (xf64-video-ati) and always got the same freeze. 

With arch + openbox, no problem for 2 weeks.

I have the same problem with fedora 15 + gnome 3. Everything will be working fine, then the gnome-shell totally freezes. I can't click anything, interact with any windows ect, but when I mouse over things I do get the rollover effects. Another strange thing is to fix this freeze I can hit alt + f2 and type r and hit enter (as you would normally do in gnome-shell) and it works. The shell restarts and responds. But when I do this I do it blindly, I don't see the run box actually come up at all.

I had this problem using r300g with a R500 card, Since I removed the card to use the onboard RS780 (r600g) a few weeks ago, I never had the problem again...

Forgot to mention my specs in my previous comment. I am using intel ironlake graphics. I will try grab some logs next time it happens.

Created attachment 197315 [details]
xsession log

To chime in here.
I can reliably get the problem when watching video.
The video stream freezes but the audio keeps on.
I have not noticed any video problems at the point of freeze.
It is like it has completely rendered a frame and is hung up on a frame switch.
The freezes also seem to be of variable time from a fraction of a second up to a minute or more.


01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics]
Chipset: "ATI Radeon HD 3200 Graphics" (ChipID = 0x9612)
mesa-dri-drivers-7.11-1.fc15.x86_64
mesa-dri-llvmcore-7.11-0.16.20110709.0.fc15.x86_64
mesa-libGLU-7.11-1.fc15.x86_64
mesa-dri-filesystem-7.11-1.fc15.x86_64
mesa-libGL-7.11-1.fc15.x86_64
xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64
xorg-x11-drv-ati-6.14.1-2.20110525gitfe5c42f51.fc15.x86_64

Hey everyone, 

same happening to me, also it seems it happens most of the time, when i scroll in firefox. I run Ubuntu natty 11.04 and just installed gnome-shell from the gnome3-ppa..

my graphics:


01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400
	Subsystem: Lenovo Thinkpad T60 model 2007
	Kernel driver in use: radeon
	Kernel modules: radeon

if you need any more info, i will be happy to provide...

Is this still an issue in 3.2?

Yes, I just had this happen in ubuntu 11.10 running gnome/gnome-shell 3.2. Exact same freeze, gui goes unresponsive but I can still hear stuff in the background, and if I can manage to restart the shell everything comes back.

Haven't been able to pinpoint exactly when it happens, it seems pretty random.

Yes, in my case it is.

Gnome-shell freezes occasionally (1-5 times a day) using 100% of the CPU power
on my box.
If you kill (SIGKILL - SIGTERM does not work) the shell, it is respawned and
you can go on working. Still nothing in logs.

Im am running the F16 with latest updates.

01:00.0 VGA compatible controller: ATI Technologies Inc Redwood PRO [Radeon HD
5500 Series] (prog-if 00 [VGA controller])
    Subsystem: PC Partner Limited Device e163
    Flags: bus master, fast devsel, latency 0, IRQ 52
    Memory at e0000000 (64-bit, prefetchable) [size=256M]
    Memory at f7bc0000 (64-bit, non-prefetchable) [size=128K]
    I/O ports at b000 [size=256]
    Expansion ROM at f7ba0000 [disabled] [size=128K]
    Capabilities: <access denied>
    Kernel driver in use: radeon
    Kernel modules: radeon

Still the same story

Hi guys built myself several debug versions and here is what I have. Problem seems to be in dri2.c. I assume, something (wrong pointer) makes it wait too long time, but I need to investigate it. Until then you can look at my debug log.

Created attachment 199254 [details]
gdb output

Hi girls, so I found it. My computer get freezes in this pool

ret = poll(&fd, 1, -1);

it's in libxcb-1.7/src/xcb_conn.c:313 .

It's obvious there must be kind of race condition or whatever and something eats things in socket before I get there, so then I sleep there for eternity. (Since debug versions of libraries are bit slower, my system was more stable and it took a while to freeze it.)

So this really doesn't seem to be Gnome bug, but I am not sure if it's libX11/libGL/libxcb issue.

Since I am running X just locally I 'fixed it' like this:

ret = poll(&fd, 1, 1000);

I am not interested in any big cod review, and I hope libraries are able to handle null event(buffer) ;)

I wonder how it gona behave.

Just reporting in that I have the same issue on Ubuntu 11.10 32bit and Gnome 3.2 with an nVidia GT430 using driver version 280.13.

My shell freezes several times per day, most often when switching desktops.  All of the apps are still running but no shell activity works.  I can still click on menus and things within the apps themselves.  Sending SIGHUP to the gnome-shell process gives me my desktop back without losing anything.

I have exactly the same problem as describe by amnesia.

Gnome-shell often freezes, specialy when I unlock gnome-screensaver.

My system : Archlinux 64 bits, kernel-3.0.7, mesa-7.11, xorg-server-1.11.1.901 and
gnome-shell-3.2.1 with an ATI Mobility Radeon HD5470 with the radeon driver.(everything works great with Gnome 3.0, and I can't reproduce this bug with another laptop with Intel graphics).

I initialy report a bug here : https://bugs.freedesktop.org/show_bug.cgi?id=41592

For me this was caused by a gnome-shell extension (gnome-shell-extensions-mediaplayer) This was fixed by the extension author in the latest version, if anyone is using this I recommend you try updating it.

bwat47, thanks ! I uninstalled gnome-shell-extensions-mediaplayer, and it seems that it solves my problem.

Anybody here isn't using gnome-shell-extensions-mediaplayer and experiences the freeze?

I never used such an extension and I experienced freezes even without any extension.

Me neither. Never used any GNOME shell extensions.

Only extension I have is the user-theme extension.

Has anyone figured out a successful workaround for this yet?  I have been trying various things to no avail.  I'm so addicted to the wonderful new interface but it's soooo unstable :(.  Not knocking the developers, because they obviously have worked very hard on it,  but this never should have been marked as a release,  it's hardly even beta quality.  I cannot wait for the finished product though!

Developers, is the trace from comment #52 enough? Do you need more? For the record, it is:

+ Trace 229038

Jozef, did you get that by going to another VT and getting a backtrace then? DRI blocks when you switch to a VT, so it's telling us that cogl is waiting on a vblank sync.

I'm affected as well. OpenGL renderer string: Gallium 0.4 on ATI RV515.
(In reply to comment #64)
> DRI blocks when you switch to a VT, so it's telling us that cogl is waiting on
> a vblank sync.
So disabling vblank sync using 'export vblank_mode=0' should solve the problem?

Have a look at debugging methods exposed at https://live.gnome.org/GnomeShell/Debugging

I have same issue with gnome-shell and ati mobility x1200 card with RS690M chip.
My system is Arch Linux x86_64.Any other DE/WM works fine.

Same issue with ATI Radeon HD 5450, Opensuse 12.1, fglrx 11.11 and gnome 3.2. KDE and LXDE work fine.

Anybody having any luck with this, or know any workarounds?

My workaround is called XFCE. :) I don't like the way new Gnome is going anyway and I can not use constantly freezing environment either.

amnesia: Please give us answers to the questions we asked in the numerous comments on this thread. We need a backtrace: https://live.gnome.org/GnomeShell/Debugging

Well, I have no time now, to investigate this issue and I switched to XFCE also. 

I accept your critics to way how I debugged the system. But I was thinking and the result is, by coincidence my debug was correct and I really found the place where system freezes. 

The reason why I think so, is patch which I've tried. It changed behavior from freezes to crash, but didn't damaged anything else.

Yea I guess I'll switch back to XFCE too.  I'm sorry to say I'm too busy to do someone else's debugging.  This was my first time trying Gnome and I really liked the layout and some of the features were outstanding.  I hope the development team can get their act together, the code seems to be the only thing holding this back from being a great product.

(In reply to comment #73)
> Yea I guess I'll switch back to XFCE too.  I'm sorry to say I'm too busy to do
> someone else's debugging.
That's not "someone else's", that's debugging your own problem. That said, we can perfectly understand you don't have the time to do that. ;-)

> This was my first time trying Gnome and I really
> liked the layout and some of the features were outstanding.
Glad to know that.

> I hope the
> development team can get their act together, the code seems to be the only
> thing holding this back from being a great product.
In the present case, there are strong reasons to think the actual bug is in the drivers, not in the Shell. Hopefully, due to the pressure of users experiencing such problems using GNOME, the drivers will improve soon (as they've started to do). So you can retry when the next release of your distro is out.


Does somebody still want to provide a stacktrace?

Created attachment 203528 [details]
output from gdb 

I've followed the GnomeShell Debugging guide that you posted and reproduced the crash. Have I done it all right? Is it all what you need?

We do not need more backtraces, Milan, we have plenty. The issue is that we're waiting for the X server to respond to a request, which means that either X or the drivers have hung. If you're using the open-source drivers, please file a bug with your driver at https://bugs.freedesktop.org/enter_bug.cgi .

(In reply to comment #76)
> If you're using the open-source drivers, please file a
> bug with your driver at https://bugs.freedesktop.org/enter_bug.cgi .
It's already done: https://bugs.freedesktop.org/show_bug.cgi?id=41668

(In reply to comment #76)
> We do not need more backtraces, Milan, we have plenty. The issue is that we're
> waiting for the X server to respond to a request, which means that either X or
> the drivers have hung.
Sorry, I interpreted your comment #64 as saying that the trace was not correct since the Shell was just hanging because user had switched to a VT.

Przemyslaw, sorry to have wasted your time. :-/

If this is a driver problem, why does it occur with both ATI and nVidia cards?  Why does every other WM work fine?  I'm not trying to be argumentative or disrespectful, just trying to understand.

Created attachment 203677 [details]
Backtrace

This is my backtrace

(In reply to comment #79)
> If this is a driver problem, why does it occur with both ATI and nVidia cards? 
> Why does every other WM work fine?  I'm not trying to be argumentative or
> disrespectful, just trying to understand.
That's indeed a good question. One explanation might be that different bugs are being dealt with in the same report. ;-)

Anyway, the fact that it only happens to some cards really means that the bug is driver-related, even if two different drivers may trigger it.

!!! WORKAORUND !!!:
Add "irqpoll" to kernel options in GRUB (GRUB_CMDLINE_LINUX_DEFAULT line). The bug is no longer triggered!

(In reply to comment #81)
> the bug is driver-related, even if two different drivers may trigger it.
Since this kernel option work, it's not radeon bug. I've been told its probably a bad apic or msi setup for our chipset. I've been suggested to contact linux-kernel mailing list. I'll post a bug report on bugzilla.kernel.org when it will be online (the page doesn't respond).

Applied immediately, no freeze for two days.
Thank you so much!!! How did you find out of this?

(In reply to comment #83)
> Applied immediately, no freeze for two days.
> Thank you so much!!! How did you find out of this?

From there: https://bugs.freedesktop.org/show_bug.cgi?id=41668

Is this still an issue with current shell/driver versions?

(In reply to comment #85)
> Is this still an issue with current shell/driver versions?

I have not experienced any freezes for a long time.

The problem has never happened again with Fedora 17 (that's for sure) and maybe not with later versions of Fedora 16 (not so sure about this).

You will my hardware information in comment #49. Thanks for your support!

Yes it is still a problem.

I am using Debian Wheezy Beta4... But the issue was still there also from Beta2 (the first I tried with Gnome 3)

The desktop is working normally and suddenly it freezes as described above. First I thought this would be a probelm of VMWare Workstation 9, but there seems to be no one who has the same issue with that product. And since a lot of people seem to have these freezes, I suspect it is independent of VMWare. Unfortunately I can't really verify that at the moment, because I get like one freeze every two days... So This is nothing I can just try out, since I need VMWare to work...

It is fixed for a long time already, I am now on version 3.6, but this has been fixed also in 3.4 for me.

Okay maybe Debian is a bit behind? I am on GNOME 3.4.2.1...

BTW, for me this only happens immediately after switching between apps using ALT+TAB or some similar action...

I am pretty sure, Debian is behind as I am on Arch Linux, but I am also sure, that in 3.4 I have not had this issue anymore. 
On the other hand, I still have irqpoll in my kernel boot parameters, which if I remember correctly fixed it for me. Maybe without it I would still have problems. I can try it. 
Did you try the irqpoll workaround yourself?

I have the irqpoll running now :)... We will see. I think I need a week at least to verify this. Two weeks would be more safe.

Ok, I ditched the irqpoll and it seems that there is no problem with my pc anymore. This is preliminary test. If I do not report here in a week, then all is fine.