Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Michael Ekstrand
On 11/18/2011 11:36 PM, Deron Meranda wrote:
 (Oops, I originally sent this to the wrong list address ... sorry if
 anybody sees duplicates)

 Since upgrading to Fedora 16, I have experienced several periodic hard
 lock-ups of the Gnome Shell session. I never experienced such
 behaviour in F15. I am wondering if anybody else is seeing something
 similar or may have advice, or can suggest a better way for me to
 gather useful debugging information should it happen again.

 I'm running with this version (including shell extensions):

 gnome-shell-3.2.1-2.fc16.x86_64
 gnome-shell-extension-apps-menu-3.2.0-1.fc16.noarch
 gnome-shell-extension-common-3.2.0-1.fc16.noarch
 gnome-shell-extension-drive-menu-3.2.0-1.fc16.noarch
 gnome-shell-extension-mediaplayers-0-0.1.git259f96e.fc16.noarch
 gnome-shell-extension-places-menu-3.2.0-1.fc16.noarch
 gnome-shell-extension-systemMonitor-3.2.0-1.fc16.noarch

I had related problems, but most notably memory leaks (which caused 
other slowness/stalling), with the systemMonitor extension. Try taking 
it out.

- Michael


-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Genes MailLists
On 11/19/2011 12:33 AM, Deron Meranda wrote:
 Since upgrading to Fedora 16, I have experienced several periodic hard
 lock-ups of the Gnome Shell session. I never experienced such
 behaviour in F15. I am wondering if anybody else is seeing something
 similar or may have advice, or can suggest a better way for me to
 gather useful debugging information should it happen again.

..

 
 Otherwise, I don't have much else to report at this point. Any help to
 figure this out would be appreciated. Thanks.

 The symptoms you describe are strongly suggestive of a bug with the
gnome window manager itself (shell?) which very likely has crashed - the
mouse events continue to be handled by X itself but consumption by the
window manager not being available.

 I wonder if its possible to ssh in to your semi-frozen computer and
point gdb at the appropriate process?

 If you can indeed ssh in then it would be interesting to run top and
see if there is a process stuck in a loop or if (as seems most likely)
the window manager itself has crashed and died - in which case
restarting it may well revive the desktop.

  In the latter case - please attach gdb to the process (from your
remote ssh login) and leave it running until the next crash - then get a
backtrace - that should be helpful to the gnome-shell devs.

  gene

[PS please don't cross post to fedora-list@redhat - its a dead list]
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Dr. Michael J. Chudobiak
On 11/19/2011 12:36 AM, Deron Meranda wrote:
 (Oops, I originally sent this to the wrong list address ... sorry if
 anybody sees duplicates)

 Since upgrading to Fedora 16, I have experienced several periodic hard
 lock-ups of the Gnome Shell session. I never experienced such
 behaviour in F15. I am wondering if anybody else is seeing something
 similar or may have advice, or can suggest a better way for me to
 gather useful debugging information should it happen again.

Are your home folders nfs-mounted?

- Mike

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Deron Meranda
On Sat, Nov 19, 2011 at 8:27 AM, Dr. Michael J. Chudobiak
m...@avtechpulse.com wrote:
 Are your home folders nfs-mounted?

All local disk - no NFS mounts anywhere.


-- 
Deron Meranda
http://deron.meranda.us/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Deron Meranda
On Sat, Nov 19, 2011 at 7:47 AM, Michael Ekstrand mich...@elehack.net wrote:
 I had related problems, but most notably memory leaks (which caused
 other slowness/stalling), with the systemMonitor extension. Try taking
 it out.

I'm not seeing any (obvious) memory leaks; though I'll try to monitor the sizes
more closely. Also I had two lock-ups before I installed any of the
shell extensions.
-- 
Deron Meranda
http://deron.meranda.us/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Deron Meranda
On Sat, Nov 19, 2011 at 8:13 AM, Genes MailLists li...@sapience.com wrote:
  I wonder if its possible to ssh in to your semi-frozen computer and
 point gdb at the appropriate process?

Yes, that's very possible. If I know what process to attach to.
gnome-shell? or Xorg?


  If you can indeed ssh in then it would be interesting to run top and
 see if there is a process stuck in a loop or if (as seems most likely)
 the window manager itself has crashed and died - in which case
 restarting it may well revive the desktop.

I did run top once, and everything was idle, no run-away process.


  In the latter case - please attach gdb to the process (from your
 remote ssh login) and leave it running until the next crash - then get a
 backtrace - that should be helpful to the gnome-shell devs.

I can try that. But do I need to install any other packages to get ELF
symbols? When I attach to gnome-shell for example I get lots of no
debugging symbols found and this...

   Missing separate debuginfos, use: debuginfo-install
gnome-shell-3.2.1-2.fc16.x86_64

But debuginfo-install is not a recognized yum command. So what's needed?

Thanks
-- 
Deron Meranda
http://deron.meranda.us/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Elliott Chapin
Happens to me if I'm running Xscreensaver.

-- 
clients.teksavvy.com/~echapin
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Jon Ingason
2011-11-19 18:00, Deron Meranda skrev:
 symbols? When I attach to gnome-shell for example I get lots of no
 debugging symbols found and this...

 Missing separate debuginfos, use: debuginfo-install
 gnome-shell-3.2.1-2.fc16.x86_64

 But debuginfo-install is not a recognized yum command. So what's needed?

This not an yum command. Just do:

debuginfo-install gnome-shell-3.2.1-2.fc16.x86_64

Read man debuginfo-install.

 Thanks


-- 
Regards
Jon Ingason
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Re: Gnome Shell periodically locks up hard in F16

2011-11-19 Thread Genes MailLists
On 11/19/2011 12:32 PM, Jon Ingason wrote:

 This not an yum command. Just do:
 
 debuginfo-install gnome-shell-3.2.1-2.fc16.x86_64
 
 Read man debuginfo-install.


  what (s)he said above.

  Hopefully you can get a trace when it crashes ... that will help the
gnome devs. a ton ...

  good luck.

  gene/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Gnome Shell periodically locks up hard in F16

2011-11-18 Thread Deron Meranda
Since upgrading to Fedora 16, I have experienced several periodic hard
lock-ups of the Gnome Shell session. I never experienced such
behaviour in F15. I am wondering if anybody else is seeing something
similar or may have advice, or can suggest a better way for me to
gather useful debugging information should it happen again.

I'm running with this version (including shell extensions):

gnome-shell-3.2.1-2.fc16.x86_64
gnome-shell-extension-apps-menu-3.2.0-1.fc16.noarch
gnome-shell-extension-common-3.2.0-1.fc16.noarch
gnome-shell-extension-drive-menu-3.2.0-1.fc16.noarch
gnome-shell-extension-mediaplayers-0-0.1.git259f96e.fc16.noarch
gnome-shell-extension-places-menu-3.2.0-1.fc16.noarch
gnome-shell-extension-systemMonitor-3.2.0-1.fc16.noarch

Often these lock-ups occur when I'm opening or closing windows in
quick succession. However the last lock-up happened as I flung the
pointer into the upper-left corner to bring up the Gnome Shell
activities bar. Gnome hung almost instantly, and the screen output was
frozen-in-time just as the little animated circular ripple that
happens when you hit an edge got about 15-to-20 pixels away from the
corner position.

The general symptoms are that all user interaction with the display
ceases to work. The mouse pointer will still move, but nothing can be
clicked on. Keyboard entry completely stops working too; which
includes any of the hot keys such as the windows keys, alt-F?,
ctl-alt-backspace, etc. I think running applications may still able to
draw to the screen, as I saw firefox refresh some icons while it was
in a locked up state. But Gnome itself appears quite dead.

The operating system as a whole though is still working. I can login
using ssh from another machine, and kill off the hung user's gnome
session processes. Afterwards I log in again to a new session and
everything works fine.


I didn't see anything in my syslog, except at the point when I killed
the session processes, such as...

Nov 18 23:53:03 beryl pulseaudio[2563]: module-gconf.c: Unable to read
or parse data from client.
Nov 18 23:53:03 beryl gnome-session[2509]: WARNING: Detected that
screensaver has left the bus
Nov 18 23:53:03 beryl gnome-session[2509]: GConf-WARNING: Got
Disconnected from DBus.#012
Nov 18 23:53:03 beryl gnome-session[2509]: WARNING: Application
'gnome-settings-daemon.desktop' killed by signal
Nov 18 23:53:03 beryl gnome-session[2509]: WARNING: Application
'gnome-shell.desktop' killed by signal
Nov 18 23:53:33 beryl systemd-logind[1256]: Removed session 2.
Nov 18 23:53:35 beryl systemd-logind[1256]: New session 39 of user gdm.
Nov 18 23:53:35 beryl systemd-logind[1256]: Linked /tmp/.X11-unix/X0
to /run/user/gdm/X11/display.
...

The ~/.xsession-errors file is harder to decipher, mainly because it
lacks any timestamps at all and is generally quite cluttered.  I am
seeing a ton of errors like:

   ([object 
_private_Clutter_Timeline],434)@/usr/share/gnome-shell/js/ui/tweener.js:220
   '
JS ERROR: !!! message = 'global.current_event_time is not a function'
JS ERROR: !!!   Exception was: TypeError:
global.current_event_time is not a function
JS ERROR: !!! lineNumber = '292'
JS ERROR: !!! fileName = '/usr/share/gnome-shell/js/ui/keyboard.js'

But I see those even when Gnome is not locked up. I think this may be
an unrelated upstream bug,
http://mail.gnome.org/archives/commits-list/2011-November/msg01202.html


And I also caught an exception in seapplet, which is strange because I
did not see any AVC error show up in syslog. The stack trace follows:

*** glibc detected *** /usr/bin/seapplet: double free or corruption
(out): 0x0265d290 ***
=== Backtrace: =
/lib64/libc.so.6[0x368be7c606]
/lib64/libglib-2.0.so.0(g_free+0x23)[0x368ba4b793]
/usr/lib64/libgtk-x11-2.0.so.0[0x369df6ad19]
/usr/lib64/libgtk-x11-2.0.so.0[0x369dfc62f2]
/lib64/libgobject-2.0.so.0(g_closure_invoke+0x154)[0x368f60ea24]
/lib64/libgobject-2.0.so.0[0x368f620527]
/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x851)[0x368f62a141]
/lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x368f62a2e2]
/lib64/libgobject-2.0.so.0[0x368f611a47]
/lib64/libgobject-2.0.so.0(g_object_notify+0x500)[0x368f613a80]
/usr/lib64/libgtk-x11-2.0.so.0[0x369dfc9723]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3f5)[0x369df4cb05]
/usr/lib64/libgdk-x11-2.0.so.0[0x369ca6209c]
/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x1dd)[0x368ba44a7d]
/lib64/libglib-2.0.so.0[0x368ba45278]
/lib64/libglib-2.0.so.0(g_main_loop_run+0x175)[0x368ba457c5]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x369df4b9c7]
/usr/bin/seapplet[0x4021c6]
/lib64/libc.so.6(__libc_start_main+0xed)[0x368be2169d]
/usr/bin/seapplet[0x402779]
=== Memory map: 
hundreds of lines omitted here...


Otherwise, I don't have much else to report at this point. Any help to
figure this out would be appreciated. Thanks.
-- 
Deron Meranda
http://deron.meranda.us/
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe 

Gnome Shell periodically locks up hard in F16

2011-11-18 Thread Deron Meranda
(Oops, I originally sent this to the wrong list address ... sorry if
anybody sees duplicates)

Since upgrading to Fedora 16, I have experienced several periodic hard
lock-ups of the Gnome Shell session. I never experienced such
behaviour in F15. I am wondering if anybody else is seeing something
similar or may have advice, or can suggest a better way for me to
gather useful debugging information should it happen again.

I'm running with this version (including shell extensions):

gnome-shell-3.2.1-2.fc16.x86_64
gnome-shell-extension-apps-menu-3.2.0-1.fc16.noarch
gnome-shell-extension-common-3.2.0-1.fc16.noarch
gnome-shell-extension-drive-menu-3.2.0-1.fc16.noarch
gnome-shell-extension-mediaplayers-0-0.1.git259f96e.fc16.noarch
gnome-shell-extension-places-menu-3.2.0-1.fc16.noarch
gnome-shell-extension-systemMonitor-3.2.0-1.fc16.noarch

Often these lock-ups occur when I'm opening or closing windows in
quick succession. However the last lock-up happened as I flung the
pointer into the upper-left corner to bring up the Gnome Shell
activities bar. Gnome hung almost instantly, and the screen output was
frozen-in-time just as the little animated circular ripple that
happens when you hit an edge got about 15-to-20 pixels away from the
corner position.

The general symptoms are that all user interaction with the display
ceases to work. The mouse pointer will still move, but nothing can be
clicked on. Keyboard entry completely stops working too; which
includes any of the hot keys such as the windows keys, alt-F?,
ctl-alt-backspace, etc. I think running applications may still able to
draw to the screen, as I saw firefox refresh some icons while it was
in a locked up state. But Gnome itself appears quite dead.

The operating system as a whole though is still working. I can login
using ssh from another machine, and kill off the hung user's gnome
session processes. Afterwards I log in again to a new session and
everything works fine.


I didn't see anything in my syslog, except at the point when I killed
the session processes, such as...

Nov 18 23:53:03 beryl pulseaudio[2563]: module-gconf.c: Unable to read
or parse data from client.
Nov 18 23:53:03 beryl gnome-session[2509]: WARNING: Detected that
screensaver has left the bus
Nov 18 23:53:03 beryl gnome-session[2509]: GConf-WARNING: Got
Disconnected from DBus.#012
Nov 18 23:53:03 beryl gnome-session[2509]: WARNING: Application
'gnome-settings-daemon.desktop' killed by signal
Nov 18 23:53:03 beryl gnome-session[2509]: WARNING: Application
'gnome-shell.desktop' killed by signal
Nov 18 23:53:33 beryl systemd-logind[1256]: Removed session 2.
Nov 18 23:53:35 beryl systemd-logind[1256]: New session 39 of user gdm.
Nov 18 23:53:35 beryl systemd-logind[1256]: Linked /tmp/.X11-unix/X0
to /run/user/gdm/X11/display.
...

The ~/.xsession-errors file is harder to decipher, mainly because it
lacks any timestamps at all and is generally quite cluttered.  I am
seeing a ton of errors like:

  ([object 
_private_Clutter_Timeline],434)@/usr/share/gnome-shell/js/ui/tweener.js:220
  '
   JS ERROR: !!! message = 'global.current_event_time is not a function'
   JS ERROR: !!!   Exception was: TypeError:
global.current_event_time is not a function
   JS ERROR: !!! lineNumber = '292'
   JS ERROR: !!! fileName = '/usr/share/gnome-shell/js/ui/keyboard.js'

But I see those even when Gnome is not locked up. I think this may be
an unrelated upstream bug,
http://mail.gnome.org/archives/commits-list/2011-November/msg01202.html


And I also caught an exception in seapplet, which is strange because I
did not see any AVC error show up in syslog. The stack trace follows:

*** glibc detected *** /usr/bin/seapplet: double free or corruption
(out): 0x0265d290 ***
=== Backtrace: =
/lib64/libc.so.6[0x368be7c606]
/lib64/libglib-2.0.so.0(g_free+0x23)[0x368ba4b793]
/usr/lib64/libgtk-x11-2.0.so.0[0x369df6ad19]
/usr/lib64/libgtk-x11-2.0.so.0[0x369dfc62f2]
/lib64/libgobject-2.0.so.0(g_closure_invoke+0x154)[0x368f60ea24]
/lib64/libgobject-2.0.so.0[0x368f620527]
/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x851)[0x368f62a141]
/lib64/libgobject-2.0.so.0(g_signal_emit+0x82)[0x368f62a2e2]
/lib64/libgobject-2.0.so.0[0x368f611a47]
/lib64/libgobject-2.0.so.0(g_object_notify+0x500)[0x368f613a80]
/usr/lib64/libgtk-x11-2.0.so.0[0x369dfc9723]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3f5)[0x369df4cb05]
/usr/lib64/libgdk-x11-2.0.so.0[0x369ca6209c]
/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x1dd)[0x368ba44a7d]
/lib64/libglib-2.0.so.0[0x368ba45278]
/lib64/libglib-2.0.so.0(g_main_loop_run+0x175)[0x368ba457c5]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x369df4b9c7]
/usr/bin/seapplet[0x4021c6]
/lib64/libc.so.6(__libc_start_main+0xed)[0x368be2169d]
/usr/bin/seapplet[0x402779]
=== Memory map: 
hundreds of lines omitted here...


Otherwise, I don't have much else to report at this point. Any help to
figure this out would be appreciated. Thanks.

-- 
Deron Meranda