Re: SIGTRAP when sending signal on closing dbus connection

[Simon McVittie <simon mcvittie collabora co uk>]

On 16/06/15 11:28, Ignacio Casal Quinteiro wrote:
> you should not be using the same object from different threads,
> instead
> you should probably idle to the main thread and to the signal from
> there.

In the specific case of GDBus it is actually OK to use the same
GDBusConnection from different threads (GDBus is designed for that), but...

>     In short terms, the application is doing the following:
>
>     Thread 1: g_object_unref(connection);
>     Thread 2: g_dbus_connection_emit_signal(connection);

... if thread 2 does not have a guarantee that the connection will not
reach its last-unref, then it is invalid for it to do *anything* that
dereferences the connection.

As a general rule, you should never do anything with a pointer if you
cannot know that the object it points to is not going to be freed by
another thread. For reference-counted objects, holding a reference
yourself is enough to know that it will not be freed, unless there is a
refcounting bug elsewhere.

If thread 2 is already holding its own reference to the connection,
check that you don't have too many unrefs somewhere else.

>     In case more details are requried, please let me know. I can
> easily
>     reproduce the
>     issue at my place and already implemented a small test executable.

If those hints are not enough to diagnose a bug in your own code, then
yes we would need to see a failing test-case (as minimal as possible).

In particular, if you think after further analysis that there is a bug
in GDBus, we will need to see a test-case that demonstrates the bug.

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