touch-packages team mailing list archive

[Serge Hallyn <1294200@xxxxxxxxxxxxxxxxxx>]

I don't know.  libnih is still a nice library and it would be nice if it could
be fixed.  Certainly the lxcfs bug should be marked invalid since we no longer
use it.  Perhaps lxc eventually, but not yet.

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