← Back to team overview

touch-packages team mailing list archive

[Bug 1294200] Re: test linked against nih-dbus-tool-generated libraryis not thread-safe

 

No, I was wrong.  Upping the ncpus makes that apparent.

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