[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Workaround for non-thread-safety
From:       Sebastian Trüg <trueg () kde ! org>
Date:       2010-05-27 22:14:13
Message-ID: 4BFEEEB5.3030109 () kde ! org
[Download RAW message or body]

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...

Cheers,
Sebastian

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.
> 
[prev in list] [next in list] [prev in thread] [next in thread]