Bug 811902

Created attachment 577019 [details]
htop

Created attachment 582274 [details]
htop

Same bug on Ubuntu: https://bugs.launchpad.net/fedora/+source/gnome-settings-daemon/+bug/969359

Created attachment 587339 [details]
backtrace for gnome-settings-daemon 1-process

Created attachment 587340 [details]
backtrace for gnome-settings-daemon 2-process

Created attachment 587342 [details]
backtrace for dconf-service process

Created attachment 587343 [details]
backtrace for dbus-daemon process

Created attachment 589027 [details]
backtrace for gnome-settings-daemon

Created attachment 589028 [details]
backtrace for dconf worker process

Created attachment 589033 [details]
backtrace for Compositor

Created attachment 589035 [details]
backtrace for dconf-service

when it occurs Num Lock indicator is often blink.

Killing dconf worker process seems stop this, but something wrong after this:
Not work hot keys (Ctrl +Shift + L - lock comkputer, Prt Scr - make screenshot), decrease font...

Killing dconf worker process seems stop this, but something wrong after this:
Not work hot keys (Ctrl +Shift + L - lock computer, Prt Scr - make screenshot), decrease font...

Created attachment 597807 [details]
backtrace for dconf worker process

Created attachment 597808 [details]
proof screenshot

see also this GNOME bug: https://bugzilla.gnome.org/show_bug.cgi?id=679151

FWIW: Affects me, too. pkill -STOP gnome-settings lets me use my computer again...

Even happens during teh day when I am away for work.

killall -9 gnome-settings-daemon helps, but is it the right way?

dconf is indeed active as well. (noticed after killing)

Comment 12 was observed here as well.
Comment 14 was observed here as well.

I am on x86_64. You too?

This bug makes working cumbersome.
The machine is ok in the early morning.
I leave home for work and return after 9.5-10 hours.
gnome-settings-daemon is making the numlock blink feverishly and the system slowish.
So we kill gnome-settings-daemon.
Also we kill the dconf thing.
We log out. The machine completes slowly.
We log in and stuff is mostly fine again for the rest of the day and next morning.

But is this a nice way to work with the box?
Therefor I increased severity again.

Mikhail created a very nice bug report.
Bastien: please come and help fix this.

I tried the dconf-editor workaround from comment 17 yesterday.
Today I found my box without the blinking numlock. gnome-settings-daemon was still consuming one full core.
So we killed that stuff.
Logged out and logged in.

Can someone please fix this without mentioning the `upstream` mantra?

Sorry my previous backtraces not contain debugging symbols. Now I'm fixed.

Another well-reproduced the bug on my laptop on kitchen (it has little memory, and he constantly swaps) when I started google-chrome and evolution, and pressed the Num Lock situation is reproduced.

Created attachment 599575 [details]
proof screenshot

Created attachment 599576 [details]
new backtrace with all debug symbols

Created attachment 599577 [details]
new backtrace with all debug symbols making minute later

udo: may be better report to upstream?

Created attachment 599614 [details]
backtrace for dconf-service

Mikhail, in comment 17 Tobias mentions an upstream bug that doesn't show progress yet.
So how do we improve from here?

This afternoon I found a blinking numlock LED again.
So comment 22's workaround did not help at all.
What is the progress?

Hi all,

this bug shows up for me as well.
FC17 x86_64 up to date.

dconf-service and gnome-settings-daemon are taking 100% CPU and doing a lot of I/O on disk.


For me it was triggered, _each time_, when using vino-server (Gnome 3 remote desktop) on the local machine (the one having the problem). I was connected from a distant client (this one did not malfunction ever) to this local machine.

I was killing both services to restore the usability of the remote machine, and it oftently crashes the session.
Eventually both services were automatically restarted and the problem was here again, and I had to kill both services again and risking a session crash.

Temporary fix :
Using dconf-editor : uncheck the check-box from org.gnome.settings-daemon.peripherals.keyboard.remember-numlock-state.
This temporary fix works for me.
(source: https://bugzilla.gnome.org/show_bug.cgi?id=679151)


Same problem on Ubuntu : https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/969359

Bye for now
Dag

Created attachment 603269 [details]
new backtrace for gnome-settings-daemon

For me a workaround (!) was the disabling of 'remember numlock state' or whatever it was called.
The issue hasn't happened for a few days now since I did that.

(so yes I can confirm the Dag comment number 31)

FWIW: abrt choses my crashing g-s-d to be a dup of bug 716357.

Created attachment 635290 [details]
gdb backtrace when g-s-d consumes 100% cpu

I've encountered the similar issue. g-s-d now consumes 100% cpu. gdb log attached.

Looks like 100% reproducible when pressing NumLock key twice.

This has been fixed at g-s-d 3.6.2 upstream:

https://bugzilla.gnome.org/show_bug.cgi?id=679151#c34

http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=15baf34186c6b5886b26e5a37698893be36f510b

http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=5e2ab43195b0522489e17c4daef5f4b391222eae

Still an issue with 3.4.2 with currently stable F17. So a backport would be appreciated.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.