LTTng » LTTng-tools

Commit used:
============
  lttng-tools   ed22248 (HEAD, temp_bug429_bug433_patches) Apply patches for bug429 and 433
                b325dc7 (origin/stable-2.1) Fix: put session list lock around the app registration
  lttng-ust     164931d (HEAD, origin/stable-2.1) Fix: refcount issue in lttng-ust-abi.c
  userspace-rcu da9bed2 (HEAD, tag: v0.7.6) Version 0.7.6

Problem description:
====================
  ConsummerD coredump

Scenario:
=========
  During our stress test (4 different users repeatedly create, start, 
  stop, destroy, convert sessions), occasionally we have seen coredump
  from consummerD with the following gdb info:

  gdb ...
  Core was generated by `lttng-consumerd --quiet -u --consumerd-cmd-sock /var/run/lttng/ustconsumerd64/c'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x00007f960a2533f4 in pthread_mutex_lock () from /lib64/libpthread.so.0

(gdb) bt
#0  0x00007f960a2533f4 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x0000000000404d09 in consumer_add_stream (stream=0xa000000, ht=0x627960) at consumer.c:585
#2  0x000000000040903a in consumer_thread_data_poll (data=0x626fd0) at consumer.c:2378
#3  0x00007f960a2517b6 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f9609fadc6d in clone () from /lib64/libc.so.6
#5  0x0000000000000000 in ?? ()

Is the problem reproducible ?
=============================
 Yes, but not at will.
 So far, it happens 3 times after running the above stress test on 6 different nights.
 (stress test is run at least 12hrs long)