OSD hangs up applications leading to them greying out

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

In particular, can you give example of applications that were hanging, and what kind of functions they were performing when the hangs occured. Thanks.

No way to reproduce and we have released a lot of fixes since then. Turning that to low priority. Feel free to raise that again if you still experience such issues.

I'm experiencing the same symptoms. Pidgin blocks completly when it's asking notify-osd to show a message (making epiphany-browser block most of the time too). Luckily, it doesn't happen all the time, but it happens enough to be very annoying. Still, i don't have a way to reproduce it.

Examples of hanging applications are certainly pidgin and epiphany, and I think liferea hung once too. Most of the time, they hang because pidgin wants to show a notification (while just scrolling a webpage in epiphany).

I'm using jaunty with the latest updates and experienced this problem since i upgraded.

Just had a recurrance of this today on the latest updates. I do not seems to be able to reproduce this with debugging enabled. As per your comment re-raising priority as it is still occuring with the latest code.

My feeling is that the bug occurs when there are near simultaneous notifications from 2-3 applications. I just triggered it when hitting play and then hitting down-volume a numbers of times (music was loud) and an xchat notification attempted to appear. Immediatly I could no longer adjust my sound volume and both rhythmbox and xchat greyed out under compiz ... wait about 40s and then the volume OSD appeared and zoomed down to the bottom and my applications returned from limbo.

I think we are at that stage where some debug might he helpful. OSD is clearly stuck somewhere for considerable time, that must be detectable with some pretty simple additions.

Ok I again saw the same OSD hang I noticed it when totem was asked to play and it started playing and immediatly greyed out without producing a popup. Watching carefully I noted that after the 30 odd second delay that the first event that was produced was a a sound voume update. I had previously hit down volume about 5/6 times in quick sucession. After the pause there was perhaps three sound downs applied and displayed and then the totem track select appeared.

I can say there were no other events pending, nothing from xchat etc. It appears the trigger was multiple volume downs in succession. I think only the first may have happened and I am not sure any visuals appeared for it at all.

I get this as well, with Pidgin and Banshee graying out - most often seems to be receiving pidgin messages that should spawn a popup that causes both to gray out. Thought it was a pidgin issue at first but as it does affect all other osd-notify apps it seems to be the cause.

I also get this with Pidgin. It freezes my system for about 30 seconds. It will even freeze things like window-closing animations, such as the usual shrinking rectanges, which leads me to think its OSD rather than something Pidgin-specific.

I'm fully up to date on Ubuntu and its recommended updates.

$ uname -a
Linux joelparkerhenderson 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

There's no particular guarantee in the protocol/spec that the service will return immediately. Apps could use asynchronous dbus calls, and n-osd may also adopt a similar architecture.

@David -- although the application should not block on the OSD service, the fact is that the service is hanging for no reason for periods of a minute. Indeed I just had a recurrance here where it hung indefinatly. It seems to trigger bad behaviour in xchat at least which causes problems for something more important which triggers gnome-terminal to go non-responsive too (and as far as I know its not using OSD at all). I suspect OSD is doing some kind of X grab over the period it is dead.

For this recurrance OSD hung for over 2 minutes at which point i used VT-1 to grab a core off it and killed it, the machine resumed function and a _heap_ of messages came out. So many that they are still coming out now some 4 minutes after I killed it. I attach the coredump in the hope it is useful; from a karmic machine.

I'm using ubuntu karmic, and get these gray windows too. I use emesene from "bjfs" PPA and can't use it with the notifications turned on because it becomes unresponsive when some one logs in/out, etc.
In addition, the notifications look HUGE, take a look at this example (i was turning volume up):
http://www.ubuntu-pics.de/bild/36458/pantallazo_01_o80Zu7.jpg

@Daniel -- that is damn massive. You should file an independant bug about that. This bug is about the hangs triggered by OSD using applications can cause, leading to windows greyiing out under compiz until OSD finally decides to display the window.

I have just upgraded to Lucid and can confirm that this bug is still present there. Sadly.

Got the same behaviour here, Ubuntu 9.10 without Compiz. I've checked all the logs I could think of, nothing out of the ordinary. If there is any additional information I can provide to make solving this really annoying bug easier, please let me know.

Applications this has occured with:
QuodLibet, using both the original notification plugin and an optimized version written by me
XChat
Pidgin

notify-osd 0.9.24-0ubuntu1
2.6.31-20-generic #57-Ubuntu SMP x86_64 GNU/Linux

Just something I noticed trying to find the cause of the issue: some applications appear to send the icon of the notification in binary form to the dbus channel, for example emesene. The array containing the icon-data can often contain about 10'000 entries, it could be that applications listening to the dbus-channel hang because they take a while to interpret all the data or deadlock in some way?
I cannot reproduce the issue manually sending notifications through notify-send, but on the other hand in this way the icon data does not appear to get sent via dbus. Attached is an example from dbus-monitor, which shows all messages sent on dbus by a simple <user sent a message> notification from emesene.

Little addition to my post before: Happens with Compiz on 10.04 as well, so I assume this being unrelated to the Window Manager.

notify-osd 0.9.29-0ubuntu2

It may be caused by a memory leak in notify-osd (the same config as Philipp Specht).
I'm using Exaile 0.3.1.1 and it was slow today, even graying out. I've noticed that notify-osd was using a lot of memory (>500MB!).
Then it suddenly started to use more and more memory and I had to kill the notify-osd process (in about 5 minutes, it used 2GB and the system was starting to swap).
After that, it's still using a lot of memory.

I found a way to reproduce this abnormal memory usage:
1) run Exaile (I have a song in the playlist)
2) look at the memory usage of the process "notify-osd"
3) move the mouse over Exaile's icon in the notification area. A notification is displayed (the title + author of the song)
4) look at the memory usage of the process "notify-osd"
Every time I repeat the steps 2) to 4) I can see that notify-osd is using more memory.

For example, doing that 3 times, using the command: date;ps xa -o pid,rss,%mem,cmd|grep osd
I get:
mercredi 8 septembre 2010, 10:29:26 (UTC+0200)
 4565 974420 24.0 /usr/lib/notify-osd/notify-osd
 mercredi 8 septembre 2010, 10:29:33 (UTC+0200)
 4565 1021684 25.2 /usr/lib/notify-osd/notify-osd
mercredi 8 septembre 2010, 10:29:37 (UTC+0200)
 4565 1057132 26.1 /usr/lib/notify-osd/notify-osd

Another info, I don't know if it's related: for the last 3-4 days, I put the computer in hibernate mode every night.