The gmail docklet causes docky to use upwards of 70% CPU and eventually crash

Bug #552152 reported by Lee Hyde
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Docky
Incomplete
Low
Robert Dyer

Bug Description

After the most recent round of updates, which were reported to have fixed the GMail docklet in Lucid Lynx, any running instance of the GMail docklet causes Docky to consume large amounts of resources (70-90% CPU) and eventually crash. The only way to correct this is to disable the GMail docklet, kill all instances of Docky and restart Docky sans the GMail docklet.

Incidentally attempting to quit Docky via its built in menu (the anchor icon) simply causes Docky to freeze and using the force quit applet, while eliminated all obvious/visual signs of Docky leaves the Docky process in tact and still over-stressing the CPU. The only way to get rid of Docky is to kill the process from within the system monitor and/or issue a killall command in terminal.

Tags: cpu gmail
Revision history for this message
Robert Dyer (psybers) wrote :

You need to give us a trace:

kill -SIGQUIT $(ps x|grep Docky.exe|grep -v grep|awk '{ print $1; }')

This will dump the trace onto Docky's terminal. So you can either start Docky from a terminal (and the trace will show up there) or figure out where Docky sent its output (usually ~/.xsession-errors) if you did not start it from a terminal.

tags: removed: crash docky
Changed in docky:
assignee: nobody → Robert Dyer (psybers)
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Lee Hyde (anubeon) wrote :
Download full text (4.1 KiB)

I opted to run docky in terminal, although I did not include the debug parameter (i.e. docky --debug). Should I have?

Docky terminal output follows:

ch2lah@SBCS625LHLT:~$ docky
[Info 10:44:28.463] Docky version: 2.1.0 bzr docky r1229 ppa
[Info 10:44:28.473] Kernel version: 2.6.32.18
[Info 10:44:28.475] CLR version: 2.0.50727.1433
/usr/share/themes/airlines/gtk-2.0/gtkrc:86: Murrine configuration option "scrollbar_color" is no longer supported and will be ignored.
/usr/share/themes/airlines/gtk-2.0/gtkrc:91: Murrine configuration option "gradients" is no longer supported and will be ignored.
/home/ch2lah/.themes/elementary-mod/gtk-2.0/gtkrc:78: Murrine configuration option "gradients" is no longer supported and will be ignored.
/home/ch2lah/.themes/elementary-mod/gtk-2.0/gtkrc:78: Murrine configuration option "gradients" is no longer supported and will be ignored.
/home/ch2lah/.themes/elementary-mod/gtk-2.0/gtkrc:78: Murrine configuration option "gradients" is no longer supported and will be ignored.
/home/ch2lah/.themes/elementary-mod/gtk-2.0/gtkrc:78: Murrine configuration option "gradients" is no longer supported and will be ignored.

** (liferea:7561): WARNING **: Liferea seems to be running already!
/home/ch2lah/.themes/elementary-mod/gtk-2.0/gtkrc:78: Murrine configuration option "gradients" is no longer supported and will be ignored.
/usr/lib/pymodules/python2.6/deluge/ui/gtkui/torrentdetails.py:304: Warning: invalid unclassed pointer in cast to `GtkMenu'
  self.menu_tabs.set_submenu(menu)
/usr/lib/pymodules/python2.6/deluge/ui/gtkui/torrentdetails.py:304: Warning: g_object_ref: assertion `G_IS_OBJECT (object)' failed
  self.menu_tabs.set_submenu(menu)
pyxmpp module is required to work properly, notificazion won't be sent
/usr/lib/pymodules/python2.6/deluge/core/core.py:496: DeprecationWarning: Use get_session_status().
  warnings.warn("Use get_session_status().", DeprecationWarning)
/usr/lib/pymodules/python2.6/deluge/core/core.py:611: DeprecationWarning: Use get_session_status().
  warnings.warn("Use get_session_status().", DeprecationWarning)
** Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
** Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[Error 10:55:13.212] Key "docky/Password" not found in keyring
[Error 10:55:13.215] gnome-keyring-daemon could not be reached!
** Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
/usr/lib/pymodules/python2.6/deluge/ui/gtkui/torrentdetails.py:304: Warning: invalid uninstantiatable type `<invalid>' in cast to `GtkMenu'
  self.menu_tabs.set_submenu(menu)
/usr/lib/pymodules/python2.6/deluge/u...

Read more...

Revision history for this message
Lai Jiang (laijiang) wrote :

I've also encountered the same problem using Lucid and the latest build of docky. However this occurs randomly. But after several checking gmail docky will eventually hang if it doesn't hang in the first time.

Revision history for this message
Robert Dyer (psybers) wrote :

Can one of you please give the trace I asked for?

Revision history for this message
Lai Jiang (laijiang) wrote :

jianglai@nerd:/var/log$ kill -SIGQUIT $(ps x|grep Docky.exe|grep -v grep|awk '{ print $1; }')
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
jianglai@nerd:/var/log$ docky
[Info 11:40:08.273] Docky version: 2.1.0 bzr docky r1229 ppa
[Info 11:40:08.282] Kernel version: 2.6.33.20633
[Info 11:40:08.284] CLR version: 2.0.50727.1433

There is nothing more, how exactly am I supposed to get the trace? Sorry for the dum question

Revision history for this message
Robert Dyer (psybers) wrote :

Here is how to get the trace:

1) start Docky from a terminal
2) open a NEW terminal
3) in the new terminal, run: kill -SIGQUIT $(ps x|grep Docky.exe|grep -v grep|awk '{ print $1; }')
4) the trace should appear in the *first* terminal (where you started Docky)

Revision history for this message
Lee Hyde (anubeon) wrote :

Oops!

It appear that I misconstrued your instructions Robert; I thought you meant that I could either run the above terminal command and locate the trace OR run Docky from the terminal. I was thus under the impression that what I posted, the output in the terminal was the trace. Forgive my ignorance.

I'm now labouring under the assumption that if I run Docky from the terminal and issue the above kill command this 'trace' you speak of will be dumped into said terminal. I just started Docky (with the GMail docklet active) in the terminal and shall post the trace here as soon as excessive resource usage occurs. But as Lai stated above, the issue occurs at random intervals; it could be a 2 minute wait or a 2 hour wait.

Lee.

Revision history for this message
Lee Hyde (anubeon) wrote :
Download full text (9.7 KiB)

I *hope* that this is what you're looking for Robert:

ch2lah@SBCS625LHLT:~$ docky
[Info 16:53:29.137] Docky version: 2.1.0 bzr docky r1229 ppa
[Info 16:53:29.147] Kernel version: 2.6.32.18
[Info 16:53:29.148] CLR version: 2.0.50727.1433

** (Docky:11136): CRITICAL **: file gkr-operation.c: line 358 (gkr_operation_request): should not be reached

** (Docky:11136): CRITICAL **: file gkr-operation.c: line 358 (gkr_operation_request): should not be reached

(Docky:11136): Wnck-WARNING **: Property _NET_WM_VISIBLE_NAME contained invalid UTF-8

(Docky:11136): Wnck-WARNING **: Property _NET_WM_VISIBLE_NAME contained invalid UTF-8

(Docky:11136): Wnck-WARNING **: Property _NET_WM_VISIBLE_NAME contained invalid UTF-8

** (gnome-system-monitor:11998): WARNING **: SELinux was found but is not enabled.

Full thread dump:

"<unnamed thread>" tid=0x0x7f0a50d3f740 this=0x0x7f0a50bc1e58 thread handle 0x404 state : not waiting owns ()
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0x00052>
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff>
  at Gtk.Application.Run () <0x0000b>
  at Docky.Docky.Main (string[]) <0x00277>
  at (wrapper runtime-invoke) Docky.Docky.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff>

"<threadpool thread>" tid=0x0x7f0a33dfe710 this=0x0x7f0a3cba5660 thread handle 0x46e state : interrupted state owns ()
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0x0004b>
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitAny (System.Threading.WaitHandle[],System.TimeSpan,bool) <0x00077>
  at System.Threading.RegisteredWaitHandle.Wait (object) <0x000bb>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>

"<unnamed thread>" tid=0x0x7f0a3c9c6710 this=0x0x7f0a44156d38 thread handle 0x41e state : interrupted state owns ()
  at (wrapper managed-to-native) System.Threading.Thread.Sleep_internal (int) <0x00045>
  at (wrapper managed-to-native) System.Threading.Thread.Sleep_internal (int) <0xffffffff>
  at System.Threading.Thread.Sleep (int) <0x0001f>
  at CPUMonitor.CPUMonitorDockItem.<CPUMonitorDockItem>m__0 () <0x00023>
  at Docky.Services.SystemService/<RunOnThread>c__AnonStorey9.<>m__B () <0x00021>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff>

"<threadpool thread>" tid=0x0x7f0a33fff710 this=0x0x7f0a441562f0 thread handle 0x46b state : interrupted state owns ()
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0x0004b>
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitAny (System.Threading.WaitHandle[],System.TimeSpan,bool) <0x00077>
  at System.Threading.RegisteredWaitHandle.Wait (object) <0x000bb>
  at (wrapper runtime-inv...

Read more...

Revision history for this message
Lai Jiang (laijiang) wrote :
Download full text (9.6 KiB)

Here is what I got. The hanging starts after the [Error] message appears

jianglai@nerd:~$ docky
[Info 12:59:04.961] Docky version: 2.1.0 bzr docky r1229 ppa
[Info 12:59:04.970] Kernel version: 2.6.33.20633
[Info 12:59:04.972] CLR version: 2.0.50727.1433
Full thread dump:

"<unnamed thread>" tid=0x0xb753d6f0 this=0x0x2fed8 thread handle 0x404 state : not waiting owns ()
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0x00004>
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff>
  at Gtk.Application.Run () <0x0000a>
  at Docky.Docky.Main (string[]) <0x00222>
  at (wrapper runtime-invoke) Docky.Docky.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff>

"<threadpool thread>" tid=0x0xb17d4b70 this=0x0x16a000 thread handle 0x434 state : interrupted state owns ()
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0x00004>
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitAny (System.Threading.WaitHandle[],System.TimeSpan,bool) <0x000f8>
  at System.Threading.RegisteredWaitHandle.Wait (object) <0x00094>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>

"<threadpool thread>" tid=0x0xb15c6b70 this=0x0x2f320 thread handle 0x43a state : interrupted state owns ()
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0x00004>
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitAny (System.Threading.WaitHandle[],System.TimeSpan,bool) <0x000f8>
  at System.Threading.RegisteredWaitHandle.Wait (object) <0x00094>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>

"<threadpool thread>" tid=0x0xb19deb70 this=0x0x16a190 thread handle 0x42e state : interrupted state owns ()
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0x00004>
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitAny (System.Threading.WaitHandle[],System.TimeSpan,bool) <0x000f8>
  at System.Threading.RegisteredWaitHandle.Wait (object) <0x00094>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>

"<threadpool thread>" tid=0x0xb1cedb70 this=0x0x16a3e8 thread handle 0x425 state : interrupted state owns ()
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0x00004>
  at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAny_internal (System.Threading.WaitHandle[],int,bool) <0xffffffff>
  at System.Threading.WaitHandle.WaitAny (System.Threading.WaitHandle[],System.TimeSpan,bool) <0x000f8>
  at System.Threading.RegisteredWaitHand...

Read more...

Revision history for this message
Robert Dyer (psybers) wrote :

Ok I see, this is a problem with Lucid and gnome keyring daemon not being supported by its Mono bindings currently.

Revision history for this message
Benjamin Humphrey (humphreybc) wrote :

I too can confirm this. I don't believe it's a duplicate of 529080.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.