Bug 1029013

Summary: dbus-daemon goes to 100% CPU
Product: Red Hat Enterprise Linux 7 Reporter: Matěj Cepl <mcepl>
Component: dbusAssignee: Colin Walters <walters>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.0CC: dcbw, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 1:1.6.12-6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 11:25:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
0001-_dbus_babysitter_unref-avoid-infinite-loop-if-waitpi.patch none

Description Matěj Cepl 2013-11-11 13:27:31 UTC 
Description of problem:
I don't have much information for this bug. Just that suddenly dbus-daemon was running at 100% CPU on one core (fortunately I have more of them, so computer was not frozen) and even systemctl restart dbus.service didn't help. Immediately after that it went to 100% CPU again. Now, I have restarted whole system, and it didn't happen so far.

When the dbus-daemon was at 100% the backtrace I have collected was

0x00007f94e392c3ba in _dbus_babysitter_unref (sitter=0x7f94e4663820) at dbus-spawn.c:317
317                   if (errno == EINTR)
(gdb) thread apply all backtrace

Thread 2 (Thread 0x7f94e1fff700 (LWP 32641)):
#0  0x00007f94e275cbdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f94e3296aff in poll (__timeout=-1, __nfds=1, __fds=0x7f94e1ffe9a0) at /usr/include/bits/poll2.h:46
#2  avc_netlink_receive (buf=buf@entry=0x7f94e1ffe9f0 "", blocking=blocking@entry=1, buflen=1024) at avc_internal.c:108
#3  0x00007f94e3296f5b in avc_netlink_loop () at avc_internal.c:257
#4  0x00007f94e2c41de3 in start_thread (arg=0x7f94e1fff700) at pthread_create.c:308
#5  0x00007f94e27671ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7f94e38b6840 (LWP 32639)):
#0  0x00007f94e392c3ba in _dbus_babysitter_unref (sitter=0x7f94e4663820) at dbus-spawn.c:317
#1  0x00007f94e38f7b7b in bus_pending_activation_unref (pending_activation=0x7f94e46636f0) at activation.c:194
#2  0x00007f94e391f0be in free_entry_data (table=0x7f94e465b410, table=0x7f94e465b410, entry=0x7f94e4663208, entry=0x7f94e4663208) at dbus-hash.c:445
#3  _dbus_hash_table_unref (table=0x7f94e465b410) at dbus-hash.c:395
#4  0x00007f94e38f7e5d in bus_activation_unref (activation=0x7f94e464d890) at activation.c:969
#5  0x00007f94e38f982f in bus_context_unref (context=0x7f94e464b0e0) at bus.c:1067
#6  0x00007f94e38f66a6 in main (argc=<optimized out>, argv=<optimized out>) at main.c:643
(gdb)


Version-Release number of selected component (if applicable):
dbus-1.6.12-5.el7.x86_64

How reproducible:
happened once, but it was persistent then

Steps to Reproduce:
1.no idea
2.
3.
Comment 2 Colin Walters 2013-11-11 15:16:32 UTC 
This is an easy and obvious patch to backport.
Comment 3 Dan Williams 2013-11-11 19:39:19 UTC 
Created attachment 822612 [details]
0001-_dbus_babysitter_unref-avoid-infinite-loop-if-waitpi.patch

Attaching the upstream fix just for kicks.
Comment 5 Matěj Cepl 2014-02-12 15:11:14 UTC 
Yes, I haven't seen this in a while. Having dbus-1.6.12-8.el7.x86_64 and I am pretty happy with it.
Comment 6 Ludek Smid 2014-06-13 11:25:25 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.