notify-osd runs at 100% of CPU locking up X

[J Jones]

Trying to run 9.04 live CD and every time I adjust the volume with the knob on the side of my laptop, the notify-osd process goes to 100% of cpu and stays there making X effectively lock up. The mouse cursor is still visible and moves, but nothing else works. When I switch to a console, and run top, I see notify-osd at 100%. If I kill the process, notify-osd just comes back and resumes using 100% of CPU.

I'm on an Toshiba Satellite laptop. Model U-305-s7449.

This is very reproducible and happens within seconds of touching the volume knob (which works fine in 8.04).

I'll play around with this more later. I'm not exactly a newbie, but I'm not a programmer either so some hints to diagnose this would be welcome.

[J Jones (johnjones)]

A little more about this bug. I've been playing around with this some more and the notify-osd process seems to behave just fine until I touch the volume knob on the side of the laptop. I can adjust the volume using the mouse and the volume icon at the top of the screen with no problems.

Also I can trigger notifications for other reasons (like connect and disconnect from wifi) and notify-osd wakes for a second or two, shows the notification, then goes back to "sleep".

However, if I even touch the volume knob, the volume notification pops up and runs away to maximum or minimum volume and begins to consume 100% CPU. Killing the process doesn't do any good, because it just restarts.

As long as I don't touch the volume knob, everything is fine. In fact, I'm typing this now from the Live CD. I'm afraid to install 9.04 to replace 8.04 because I don't want to have a runaway volume notification every time I touch the volume.

Is there anything else that would be helpful to diagnose this? lspci printout or something similar?

Let me know and I'll post whatever.

[J Jones (johnjones)]

I just ran the system test and submitted the results. I don't know if you can access that via my email address, but it seemed to have all of my hardware information included.

[J Jones (johnjones)]

Here are the results of the system test.

[J Jones (johnjones)]

Here they are in a more readable format.

[Mirco Müller (macslow)]

Could you try the attached scripts with your system running 9.04 from the live CD. Do both/just one/none max out too?

[Mirco Müller (macslow)]

Please note that these two test-scripts will not change the systems volume at all. They just trigger the pure notifications.

[J Jones (johnjones)]

I downloaded and ran the scripts. I got the message that the command "notify-send" was not installed, so I installed the package libnotify-bin and ran them again.

Both scripts seem to work just fine. The notification popped up, showed an "increasing volume" and then the notifications disappeared and notify-osd went back to sleep.

Maybe the problem has something to do with the signal being received from the volume knob. When I move the knob slightly, the notification should show a slight change in the volume then go back to sleep. Instead, the notification seems to think that I am continuing to move the knob and goes to max or min volume. It's like there's an endless loop in the code somewhere related to the signal from the volume knob.

Anything else I should try? Perhaps a script that actually changes the volume? Remember, I can change the volume with the mouse and slider bar with no problems.

[Mirco Müller (macslow)]

Ok, with the two scripts I wanted to make sure it's not the actual rendering-code of notify-osd. So this looks like it's happening "outside" of notify-osd. I'm guessing some quirky issue in gnome-settings-daemon, which triggers the notification, could be the cause. Or some dbus-related issue.

[David Barth (dbarth)]

Hi,

To narrow down the problem, could you send us a debug log

As a normal user, in a terminal:
  killall notify-osd ; DEBUG=1 /usr/lib/notify-osd/notify-osd > n-osd.log

Then, use volume buttons to trigger the bug.

Then CTRL-C to terminate notify-osd and get the debug log. Please mention if the CPU goes back to normal once notify-osd is killed.

Thanks

[J Jones (johnjones)]

So I ran the debug command and then barely moved the volume knob to increase the volume. The notification popped up and immediately ran away to max volume. I did CTRL-C to kill the process, but it immediately restarted and went right back to 100% CPU with the notification box flashing. However after about 20 seconds, the notification went away and notify-osd went back to sleep.

So I tried it again. Ran the debug command and nudged the volume knob. Same result except this time, after CTRL-C, the notify-osd process never went back to sleep. I had to reboot with the power button.

The log file attached below is from the second run.

Some other observations about the behavior when it is "locked up." It's not completely locked up and the mouse seems to work, but the keyboard and the panels don't work. I don't know if that's important, but there it is.

[J Jones (johnjones)]

Not sure why work on this bug has stopped???

I've discovered that if I kill the process gnome-settings, then I can recover the computer to a usable state. Some of the ubuntu-specific appearance tweaks are gone (back to the standard gnome panel for instance), but everything works. If I use the system for a while without touching the volume knob, then eventually I trigger gnome-settings to restart somehow and everything goes back to normal with the default ubuntu appearance.

Maybe this bug report should be moved to the package gnome-settings.

And I'm not sure how to find out if gnome-settings has been updated from what was on the original 9.04 distribution CD.

Thanks for the help. This bug is the only reason that I haven't yet upgraded to 9.04. Otherwise this is a fabulous version of Ubuntu.

[J Jones (johnjones)]

Looks like this might be a duplicate of bug 335201

[J Jones (johnjones)]

I'm the original submitter and ran across another bug report that describes this behavior for Toshiba laptops and other laptops without sound adjustment keys. Most of the troubleshooting work has already been done on that bug report, so I'm marking this bug as a duplicate of 271706. This is definitely the same problem that has been evident since about Ubuntu 8.10.