Should we close this bug now that we're no longer using libnih in lxcfs and are moving away from cgmanager too for this very threading reason?
-- 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: Fix Released Status in dbus package in Ubuntu: Invalid Status in libnih package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Confirmed Status in lxcfs package in Ubuntu: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
