На "Эльбрус 801-РС" под бетой Альт Образование 9.0 (20191126) получается воспроизводимо уронить gcompris-qt либо gcompris при начале работы с модулем (клавиатура -- самый первый -- в случае -qt, шахматы -- первый снизу -- в случае старого варианта). В консоли получаем идентичное: Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. Aborted Вот этот кусок src/pulsecore/mutex-posix.c (файл не менялся с 2014): 105 void pa_mutex_unlock(pa_mutex *m) { 106 pa_assert(m); 107 108 pa_assert_se(pthread_mutex_unlock(&m->mutex) == 0); 109 } Точечное обновление до 13.0 из sisyphus_e2k, разумеется, ничего не меняет. На sisyphus/x86_64 у george@ воспроизвести не удалось.
backtrace такой: Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. Thread 4 "aqueue:src" received signal SIGABRT, Aborted. [Switching to Thread 0x455561ffeee0 (LWP 19882)] 0x0000455558390d70 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0000455558390d70 in raise () from /lib64/libc.so.6 #1 0x00004555583986f8 in abort () from /lib64/libc.so.6 #2 0x000045555b6c3170 in pa_mutex_unlock () from /usr/lib64/pulseaudio/libpulsecommon-13.0.so #3 0x000045555b4b89f0 in ?? () from /usr/lib64/gstreamer-1.0/libgstpulseaudio.so #4 0x0000455559c8aa00 in gst_audio_ring_buffer_commit () from /usr/lib64/libgstaudio-1.0.so.0 #5 0x0000455559c0cfa0 in ?? () from /usr/lib64/libgstaudio-1.0.so.0 #6 0x000045555a0a9a78 in gst_base_sink_chain_unlocked () from /usr/lib64/libgstbase-1.0.so.0 #7 0x000045555a0ab6a8 in gst_base_sink_chain () from /usr/lib64/libgstbase-1.0.so.0 #8 0x0000455557b37968 in gst_pad_chain_data_unchecked () from /usr/lib64/libgstreamer-1.0.so.0 #9 0x0000455557b3ab98 in gst_pad_push_data () from /usr/lib64/libgstreamer-1.0.so.0 #10 0x0000455557b3beb8 in gst_pad_push () from /usr/lib64/libgstreamer-1.0.so.0 #11 0x0000455557adee60 in gst_proxy_pad_chain_default () from /usr/lib64/libgstreamer-1.0.so.0 #12 0x0000455557b37968 in gst_pad_chain_data_unchecked () from /usr/lib64/libgstreamer-1.0.so.0 #13 0x0000455557b3ab98 in gst_pad_push_data () from /usr/lib64/libgstreamer-1.0.so.0 #14 0x0000455557b3beb8 in gst_pad_push () from /usr/lib64/libgstreamer-1.0.so.0 #15 0x000045555a101688 in gst_base_transform_chain () from /usr/lib64/libgstbase-1.0.so.0 #16 0x0000455557b37968 in gst_pad_chain_data_unchecked () from /usr/lib64/libgstreamer-1.0.so.0 #17 0x0000455557b3ab98 in gst_pad_push_data () from /usr/lib64/libgstreamer-1.0.so.0 #18 0x0000455557b3beb8 in gst_pad_push () from /usr/lib64/libgstreamer-1.0.so.0 #19 0x000045555a101688 in gst_base_transform_chain () from /usr/lib64/libgstbase-1.0.so.0 #20 0x0000455557b37968 in gst_pad_chain_data_unchecked () from /usr/lib64/libgstreamer-1.0.so.0 #21 0x0000455557b3ab98 in gst_pad_push_data () from /usr/lib64/libgstreamer-1.0.so.0 #22 0x0000455557b3beb8 in gst_pad_push () from /usr/lib64/libgstreamer-1.0.so.0 #23 0x0000455557adee60 in gst_proxy_pad_chain_default () from /usr/lib64/libgstreamer-1.0.so.0 #24 0x0000455557b37968 in gst_pad_chain_data_unchecked () from /usr/lib64/libgstreamer-1.0.so.0 #25 0x0000455557b3ab98 in gst_pad_push_data () from /usr/lib64/libgstreamer-1.0.so.0 #26 0x0000455557b3beb8 in gst_pad_push () from /usr/lib64/libgstreamer-1.0.so.0 #27 0x000045555a35d578 in ?? () from /usr/lib64/gstreamer-1.0/libgstcoreelements.so #28 0x000045555a35ef00 in ?? () from /usr/lib64/gstreamer-1.0/libgstcoreelements.so #29 0x0000455557be63b8 in gst_task_func () from /usr/lib64/libgstreamer-1.0.so.0 #30 0x0000455557be9498 in default_func () from /usr/lib64/libgstreamer-1.0.so.0 #31 0x0000455557efec18 in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0 #32 0x0000455557efda90 in g_thread_proxy () from /lib64/libglib-2.0.so.0 #33 0x00004555582e78e0 in start_thread () from /lib64/libpthread.so.0 #34 0x0000455558657ad0 in __thread_start () from /lib64/libc.so.6 #35 0x00004555582e5be8 in create_thread () from /lib64/libpthread.so.0
Возможные виновники: 1) glibc (см. https://bugzilla.redhat.com/show_bug.cgi?id=513854 и https://bugzilla.redhat.com/show_bug.cgi?id=513629). 2) gstreamer (см. backtrace выше). 3) ядро (т.к. там реализуются PI mutex). 3) pulseaudio тоже может быть виноват, но в данном случае это менее вероятно.
Наиболее вероятно, что это проблема glibc (bad introduction and usage of __ASSUME_REQUEUE_PI): https://at.projects.genivi.org/jira/si/jira.issueviews:issue-html/GDP-433/GDP-433.html Исправлено в glibc commit ed19993b5b0d05d62cc883571519a67dae481a14: New condvar implementation that provides stronger ordering guarantees. Там полностью передланная реализация и много кода. Буду пытаться портировать на e2k glibc. Получится ли — не знаю, поможет ли — тоже не известно.
Проблема исправлена в glibc-2.23-alt3.E2K.16. Скоро соберу в репозиторий (пока тестировал локальную сборку). Пришлось несколько кусков glibc-2.25 бекпортировать.
Забыл статус поменять.
Спасибо!