dbus_connection_read_write_dispatch sometimes causing 100% cpu usage

[Ray Strode]

Hi,

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?

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

--Ray