dbus_connection_read_write_dispatch sometimes causing 100% cpu usage

[Burton Samograd]

Ray Strode <halfline at gmail.com> writes:

> On Fri, Sep 10, 2010 at 3:32 PM, Havoc Pennington <hp at pobox.com> wrote:
>> This makes me suspect you're recursing and re-entering dispatch
>> (trying to _dbus_connection_acquire_dispatch() twice without releasing
>> it)
>>
>>> Here is a stack trace from where I am in the loop:
>>>
>>> #0  _dbus_connection_acquire_dispatch (connection=0x1053c00) at dbus-connection.c:3864
>>> #1  0x00007f96c57726bb in dbus_connection_dispatch (connection=0x1053c00) at dbus-connection.c:4303
>>> #2  0x00007f96c5770654 in _dbus_connection_read_write_dispatch (connection=0x1053c00,
>>>    timeout_milliseconds=100, dispatch=1) at dbus-connection.c:3431
>>> #3  0x00007f96c5770a22 in dbus_connection_read_write_dispatch (connection=0x1053c00,
>>>    timeout_milliseconds=100) at dbus-connection.c:3513
>> It looks like you somehow have read_write_dispatch from inside
>> read_write_dispatch, and the inner read_write_dispatch is waiting for
>> the outer one to give up dispatch_acquired (i.e.
>> _dbus_connection_release_dispatch())
> Note frame 3 doesn't have a leading underscore and frame 2 does, so
> probably not recursion (unless gdb is hiding frames or something)
>
> Looking through the code there is one call that does
> _dbus_connection_acquire_dispatch() without doing release_dispatch
> before returning and that's
>
> dbus_connection_borrow_message
>
> So if the code was singled threaded, and called borrow_message, then
> called read_write_dispatch without first calling return_message, I
> think it would infinite loop too.  Do you use that function, Burton?

I'm not using that function, so no I don't think that would be the cause
of the problem.

> Alternatively, maybe heap corruption that valgrind would pick up on
> ...

I've been meaning to run it through valgrind but haven't had a chance to
yet.  I'll probably get around to that today and see what it can tell
me.

Thanks.

--
Burton Samograd