GNOME Bugzilla – Bug 704646
gnome-shell becomes unresponsive from time to time
Last modified: 2013-08-20 19:46:34 UTC
I often see gnome-shell becoming unresponsive. I can "unhang" it running "killall -HUP gnome-shell" in a console, but would like to know how to try to get more useful information. I have reviewed journalctl output but don't see anything related :( Thanks I am running gnome-shell-3.8.3 (plus all committed patches from gnome 3.8 branch)
Attach gdb after the hang and get a backtrace please. (Also "killall gnome-shell" would have done the same no need for -HUP).
I have abrt running and it catches all traces but this one, that is because I am really unsure about what is the status of gnome-shell when it goes to this "paused" problem :(
It is not a crash so abrt won't help you here. You have to attach gdb by hand: https://live.gnome.org/GnomeShell/Debugging
I have had multiple problems when trying to get the trace: "Immediately press CTRL-A, release, SHIFT-H. Screen will confirm that it is now recording the session to screenlog.0 or hardcopy.0, depending on your distribution. Make a note of the file name." I have pressed SHIFT-H and nothing occurred, even running under screen :/ "Attach to an existing instance: $ gdb attach $(pidof gnome-shell)" Should I attach it to just hung process? In that case, gdb tells me "attach" doesn't exist, I need to run: $ gdb gnome-shell $(pidof gnome-shell) What does I need now to do? Restart gnome-shell with --replace from here? I tried by it continued hung and needed to press Ctrl+C from gdb shell, I then was able to get a trace: $ set logging on $ t a a bt $ call gjs_dumpstack () $ set logging off
Created attachment 249938 [details] backtrace
Created attachment 249999 [details] gdb.txt This one has been generated as follows: 1. gnome-shell gets unresponsive 2. I go to tty and run "gdb gnome-shell $(pidof gnome-shell)" set logging on bt set logging off
Can you do "call gjs_dumpstack()" in gdb as well and get the stderr output?
(In reply to comment #7) > Can you do "call gjs_dumpstack()" in gdb as well and get the stderr output? Will try next time, how can I get the stderr output? If it's logged by journalctl (the old .xsession-errors stuff), nothing new is appended there when hanging)
(In reply to comment #8) > (In reply to comment #7) > > Can you do "call gjs_dumpstack()" in gdb as well and get the stderr output? > > Will try next time, how can I get the stderr output? If it's logged by > journalctl (the old .xsession-errors stuff), nothing new is appended there when > hanging) It will print something out when you call gjs_dumpstack()
(In reply to comment #7) > Can you do "call gjs_dumpstack()" in gdb as well and get the stderr output? I have just run it but outputs nothing
Created attachment 250061 [details] gdb.txt Updated trace
(In reply to comment #10) > (In reply to comment #7) > > Can you do "call gjs_dumpstack()" in gdb as well and get the stderr output? > > I have just run it but outputs nothing The output goes to stderr not to the gdb console. You can try doing call open("/dev/tty", 2) call dup2($x, 2) call gjs_dumpstack() (where x is the result you get from the first line).
I get this: (gdb) call open("/dev/tty", 2) $1 = -1 (gdb) call dup2($x, 2) $2 = 128 (gdb) call gjs_dumpstack() (gdb) set logging off
I am testing now with plain 3.8.3 gnome-shell (without applying patches from the branch). It looks to be solved now but I will wait a bit more https://git.gnome.org/browse/gnome-shell/log/?h=gnome-3-8 Not sure witch one could be the culprit https://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-8&id=1020d8a0f8523a04d8336b1348388b8b242e414f ? (I have a background changing every some minutes)
Yeah, dropping that patch solves the issue for me :O
Still the same with 3.8.4 :| (as it includes offending commit)
I've seen the same issue with 3.8.4.
I'll have a look.
Could you add your background to the bug, so I can test with it. I can't reproduce on my machine with the default background.
I wonder if this bug and bug 705732 are related.
I definitely found a memory leak in the BackgroundCache class. Every time you change of background we "leak" a MetaBackgroundContent. Even if we had that file already loaded previously. It seems there is a design problem with that component, because it doesn't seem to release memory at any point.
I cannot upload all backgrounds that are rotated because I am accessing to internet using my smartphone and it has a limited quota. But I am using Ubuntu ones on Gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/ubuntu-wallpapers/ubuntu-wallpapers-13.04.0.ebuild?view=markup As you can see, we use plain ubuntu wallpapers and don't modify them
Lionel so is there a reference to the old content still in the javascript? Does manually running the GC from LG "fix" it ?
I have just seen that, when it becomes stalled, I see this in journalctl: ago 14 10:30:15 localhost gnome-session[496]: (gnome-settings-daemon:537): power-plugin-DEBUG: Received session is active change: now inactive ago 14 10:30:15 localhost gnome-session[496]: (gnome-settings-daemon:537): mouse-plugin-DEBUG: Trying to set device enabled for 6 ago 14 10:30:15 localhost gnome-session[496]: (gnome-settings-daemon:537): mouse-plugin-DEBUG: Trying to set device enabled for 7 ago 14 10:30:15 localhost gnome-session[496]: (gnome-settings-daemon:537): mouse-plugin-DEBUG: Trying to set device enabled for 8 ago 14 10:30:15 localhost gnome-session[496]: (gnome-settings-daemon:537): mouse-plugin-DEBUG: Trying to set device enabled for 9 -> for some reason session becomes inactive, but no idea if this could be a consequence of the hang instead of a cause
I have same problem with shell on two different machines, and I was testing 3.8.4 without commit in comment #14 for some time (one session), for now, no issues, it doesn't lock-up. I was using this package for F19 ( http://koji.fedoraproject.org/koji/taskinfo?taskID=5820073 ) I'll continue testing it and if something changes, I'll report ;-)
Created attachment 251832 [details] [review] Revert "background: fix asynchronous management of background loading operations" This reverts commit 1020d8a0f8523a04d8336b1348388b8b242e414f. --- This patch seems to add more problems then it solves, so lets revert it at least for 3.8.x.
Comment on attachment 251832 [details] [review] Revert "background: fix asynchronous management of background loading operations" okay let's get this in and reopen the the bug it came from.
Attachment 251832 [details] pushed as 062235f - Revert "background: fix asynchronous management of background loading operations"
*** Bug 706030 has been marked as a duplicate of this bug. ***
*** Bug 706133 has been marked as a duplicate of this bug. ***
*** Bug 706169 has been marked as a duplicate of this bug. ***
*** Bug 706023 has been marked as a duplicate of this bug. ***
*** Bug 706026 has been marked as a duplicate of this bug. ***
*** Bug 705559 has been marked as a duplicate of this bug. ***
*** Bug 705757 has been marked as a duplicate of this bug. ***
Do you know if a 3.8.5 release is scheduled soon? (for knowing if we should get patches from 3.8 branch applied downstream if not) Thanks! :)
i'd probably go with downstream patches for now. we'll want to figure out the "right" fix first before doing a 3.8.5