Review Request: Workaround for non-thread-safety of QDBusConnection
trueg at kde.org
Thu May 27 23:14:13 BST 2010
While it is great that we have a fix I have to agree with Lubos: it will
probably take a while for distributions to update to DBus 1.4. During
that time the workaround helps preventing many crashes...
On 05/27/2010 10:46 PM, Thiago Macieira wrote:
> Em Quinta-feira 27. Maio 2010, às 16.43.20, Lubos Lunak escreveu:
>> If this is an important issue to fix, what is the patch and the problem
>> (=something specific) it fixes?
> The patch is attached to the bugzilla report that Sebastian linked to.
> It can't be applied to the current 1.2 tree because it contains a behaviour
> change in one of the basic event-loop integration callbacks.
> The issue in question is that, when libdbus-1 needs to call the callback for
> enabling, disabling or toggling timers, or socket notifiers (DBusTimeout and
> DBusWatch in libdbus-1 parlance), it needs to drop the locks. It's standard
> procedure: you're calling out to user code, you drop all locks you have in
> place, because the user may do strange things and recurse back to you.
> The problem is that, if we drop the locks, then a recursion may change the
> pointers in the structures that were being modified (think reallocation). So
> libdbus-1 has had for years now this hack that doesn't work that simply makes
> the pointer NULL to indicate that a recursion has happened.
> Couple that with threading and you have this issue happening when two separate
> threads try to send a D-Bus message at the same time: when one drops its
> locks, the other one tries to send, and finds the structures set to NULL. That
> second one fails without setting a proper error message, which in libdbus-1
> means "Out of memory".
> The fix is to *not* drop the locks and document what the binding may or may not
> do in that callback.
More information about the kde-core-devel