Re: SIGTRAP when sending signal on closing dbus connection



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]