Re: Antwort: Re: SIGTRAP when sending signal on closing dbus connection

On 16/06/15 12:45, [email protected] wrote:
> For sure it is a bad idea to use the object, if the timing is like this:
> 
> 1. g_object_unref(conn);
> 2. g_dbus_connection_emit_signal(conn); => Object is already freed. User
> deserves the crash ;)

Sure.

> But what is, if the timing is like this:
> 
> 1. g_dbus_connection_emit_signal(conn);
> 2. g_object_unref(conn);

How can you guarantee that the timing is always going to be like this,
i.e. that thread 1 always "wins the race"?

If the answer is a mutex or something, extend the scope of the mutex to
protect g_d_c_e_s() and you're fine.

If the answer is "I can't guarantee that", then you still have a bug (a
classic race condition), and still deserve the crash :-)

> I haven't seen that the "g_dbus_connection_emit_signal"obtains a
> reference to the connection!
> Shouldn't it do so, to be sure that the connection is not freed "during"
> the call?

Not really. That would make simple code where the object is not shared
between threads slower (taking a reference is not free - it's an atomic
operation which flushes CPU caches), and the only situations in which it
helps you to not crash are those where you already have a race condition
that will sometimes crash your program anyway.

If some code has broken reference-counting and is sometimes going to
crash, I'd prefer it to crash more often, so that its developer can find
and fix it.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>