kbdd
kbdd copied to clipboard
Eat 100% cpu
After start kbdd eat 100% cpu , all time.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7769 user 20 0 7180 1952 1660 R 99,7 0,1 0:10.46 kbdd
git commit - 28562b5
debian testing.
thanks, for report will check
dpkg -l | grep dbus
ii dbus 1.5.12-1 simple interprocess messaging system (daemon and utilities) ii dbus-x11 1.5.12-1 simple interprocess messaging system (X11 deps)
I was tryed debug with gdb and ddd. But know nothing about dbus and its work. So cant find what function eat all cpu. If you can help me with debugging, i will try find problem code.
It would be nice, I had some problem in one of commits, but I can't reproduce it now
Внезапно прочитал профиль и увидел питер.
Я к сожалению не понимаю как отлаживать процедуру зарегистрированную в dbus. Какой то attach делать? Но куда, как. Мой опыт тут почти нулевой.
если честно. то в данной ситуации я не могу подсказать, сейчас после нескольких дней аптайма я словил эту же ошибку, попытаюсь выжать из неё максимум информации
strace -c -p $pid показал, что-то вроде
% time seconds usecs/call calls errors syscall
38.38 0.001824 0 48236 write 21.30 0.001012 0 24118 24118 recvfrom 20.58 0.000978 0 24118 read 19.74 0.000938 0 24118 poll
100.00 0.004752 120590 24118 total
учитывя, что recvfrom напрямую не используется. то проблема видимо в получении событий от Xorg. возможно и выловую проблему
Похоже нужна помошь кого то кто отлаживать умеет ;)
в общем почему закрывается fd, использующихся для уведомления о событиях от X. сегодня запосчу 1 фикс, но наверное все проблемы он не решит
забыл запостить фикс, сейчас возможно исправится, полноценное решение проблемы сделаю в ближайшие дни
Скомпилировал. Пока cpu не жрет.
сейчас я убрал бесполезную проверку есть ли ещё события, в принципе решение проблемы может быть побочным эффектом, т.к. проблемы начинаются если по какой-либо причине сокет предоставляемый программе иксами закрывается, в этом случае kbdd начинает с дикой скоростью пытаться его опрашивать, хотя по хорошему в этом случае должна происходить переинициализация X и переключаться на прослушивание нового сокета. Как это сделать правильным образом мне пока не понятно. С одной стороны ситуация это абсолютно нештатная, с другой, раз такое происходит, то надо обрабатывать.
воспроизвести ошибку снова не смог пока закрываю баг, т.к. исходная проблема решена.
ох зря ты его закрыл