touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #68390
[Bug 1294200] Re: test linked against nih-dbus-tool-generated libraryis not thread-safe
Some of this likely is due to (acknowledged) basic thread-safety issues
in libdbus, and there is discussion on the dbus mailing list about how
to address it (in libdbus)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnih in Ubuntu.
https://bugs.launchpad.net/bugs/1294200
Title:
test linked against nih-dbus-tool-generated libraryis not thread-safe
Status in cgmanager package in Ubuntu:
Confirmed
Status in dbus package in Ubuntu:
New
Status in libnih package in Ubuntu:
New
Status in lxc package in Ubuntu:
Confirmed
Bug description:
I've taken the libnih source for trusty, and added '--enable-threads'
to the three dh_auto_configure lines in debian/rules, rebuilt ,and
installed the result. Then I took the source for cgmanager package,
rebuilt, and installed.
Finally I took github.com/cgmanager/cgmanager, copied the
configure.ac, Makefile.am, and tests/cgm-concurrent.c into the
cgmanager package source, and built tests/cgm-concurrent.c.
The cgm-concurrent.c only connects to the cgmanager dbus server, sends
a ping method, and disconnects - with one connection per thread.
When I do cgm-concurrent -i 100 -j 30 -c (meaning use 30 threads and
do 100 full iterations, and don't do any extra dbus calls), I get
pretty random dumps. Here is one example:
(gdb) where
#0 0x00007ffff71c5f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff71c9388 in __GI_abort () at abort.c:89
#2 0x00007ffff71bee36 in __assert_fail_base (fmt=0x7ffff73104b8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff756793c "mutex->__data.__owner == 0",
file=file@entry=0x7ffff7567908 "../nptl/pthread_mutex_lock.c", line=line@entry=116, function=function@entry=0x7ffff7567a40 <__PRETTY_FUNCTION__.8500> "__pthread_mutex_lock") at assert.c:92
#3 0x00007ffff71beee2 in __GI___assert_fail (assertion=0x7ffff756793c "mutex->__data.__owner == 0", file=0x7ffff7567908 "../nptl/pthread_mutex_lock.c", line=116,
function=0x7ffff7567a40 <__PRETTY_FUNCTION__.8500> "__pthread_mutex_lock") at assert.c:101
#4 0x00007ffff755f52f in __GI___pthread_mutex_lock (mutex=0xfefefefefefefe00) at ../nptl/pthread_mutex_lock.c:116
#5 0x00007ffff779fa45 in _dbus_platform_rmutex_lock (mutex=<optimized out>) at ../../dbus/dbus-sysdeps-pthread.c:156
#6 0x00007ffff77943f5 in _dbus_rmutex_lock (mutex=<optimized out>) at ../../dbus/dbus-threads.c:176
#7 0x00007ffff7782b40 in dbus_connection_get_data (connection=0x7fffc0040e70, slot=0) at ../../dbus/dbus-connection.c:5979
#8 0x00007ffff79bb766 in nih_dbus_setup () from /lib/x86_64-linux-gnu/libnih-dbus.so.1
#9 0x0000000000401cbe in cgm_dbus_connect ()
#10 0x0000000000401e5d in do_function ()
#11 0x0000000000401ec4 in concurrent ()
#12 0x00007ffff755d182 in start_thread (arg=0x7fffd8ff9700) at pthread_create.c:312
#13 0x00007ffff728a12d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Sometimes they show up in nih_free, where usually the thing being
freed has a ->next which points to a member function; sometimes they
show up in the dbus library at various points.
I may well be doing something wrong, but I don't know what. If we
can't either fix what I'm doing wrong or fix libnih or libdbus (if
those are being buggy), then I guess I'll have to mutex the connection
among all threads.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1294200/+subscriptions