Failing FIFO assertion in updateAllGuis()

[cbix]

Faced a crash on startup that I could not reproduce inside gdb (and weirdly, did not occur after that). FL is compiled with -Wp,-D_GLIBCXX_ASSERTIONS by Arch Linux defaults. Still, here's a backtrace from the core dump, there seems to be a failed FIFO assertion. This assertion might hint at a potential bug so even if it's not currently affecting most users, it could be worth looking into.

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffbf028e3d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffbf023e838 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffbf0228535 in __GI_abort () at abort.c:79
#4  0x00007ffbf022845c in __assert_fail_base
    (fmt=0x7ffbf03bfe70 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffbf03c0ce8 "new_prio == -1 || (new_prio >= fifo_min_prio && new_prio <= fifo_max_prio)", file=0x7ffbf03bc1ef "tpp.c", line=83, function=<optimized out>) at assert.c:92
#5  0x00007ffbf0237366 in __GI___assert_fail
    (assertion=0x7ffbf03c0ce8 "new_prio == -1 || (new_prio >= fifo_min_prio && new_prio <= fifo_max_prio)", file=0x7ffbf03bc1ef "tpp.c", line=83, function=0x7ffbf03c4640 <__PRETTY_FUNCTION__.0> "__pthread_tpp_change_priority") at assert.c:101
#6  0x00007ffbf0294849 in __GI___pthread_tpp_change_priority (previous_prio=previous_prio@entry=-1, new_prio=new_prio@entry=6629) at tpp.c:83
#7  0x00007ffbf028f26f in __pthread_mutex_lock_full (mutex=0x55bfcf1ab110) at pthread_mutex_lock.c:555
#8  0x000055bfce54f294 in TMutex::Lock() (this=0x55bfcf1ab108) at /usr/src/debug/faustlive-2.5.11/Build/../src/Utilities/TMutex.h:91
#9  FLInterfaceManager::updateAllGuis() (this=0x55bfcf1ab100) at /usr/src/debug/faustlive-2.5.11/src/MainStructure/FLInterfaceManager.cpp:29
#10 0x00007ffbf0b65e12 in doActivate<false>(QObject*, int, void**) (sender=0x55bfcf603920, signal_index=3, argv=0x7fffe09b43b0)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/kernel/qobject.cpp:3933
#11 0x00007ffbf0b71f9f in QTimer::timeout(QTimer::QPrivateSignal) (this=<optimized out>, _t1=...)
    at /usr/src/debug/build/src/corelib/Core_autogen/include/moc_qtimer.cpp:210
#12 0x00007ffbf0b57e76 in QObject::event(QEvent*) (this=0x55bfcf603920, e=0x7fffe09b4500)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/kernel/qobject.cpp:1333
#13 0x00007ffbf1b749dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=<optimized out>, receiver=0x55bfcf603920, e=0x7fffe09b4500)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/widgets/kernel/qapplication.cpp:3350
#14 0x00007ffbf0b13088 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x55bfcf603920, event=0x7fffe09b4500)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/kernel/qcoreapplication.cpp:1067
#15 0x00007ffbf0c6631b in QTimerInfoList::activateTimers() (this=0x55bfcf262060)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/kernel/qtimerinfo_unix.cpp:646
#16 0x00007ffbf0d322ca in timerSourceDispatch(GSource*, GSourceFunc, gpointer) (source=<optimized out>)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/kernel/qeventdispatcher_glib.cpp:185
#17 0x00007ffbe8dd4c6b in g_main_dispatch (context=0x55bfcf14b180) at ../glib/glib/gmain.c:3417
#18 g_main_context_dispatch (context=0x55bfcf14b180) at ../glib/glib/gmain.c:4135
#19 0x00007ffbe8e2b001 in g_main_context_iterate.constprop.0
    (context=context@entry=0x55bfcf14b180, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4211
#20 0x00007ffbe8dd2392 in g_main_context_iteration (context=0x55bfcf14b180, may_block=1) at ../glib/glib/gmain.c:4276
#21 0x00007ffbf0d304d2 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x55bfcf0ff6f0, flags=...)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/kernel/qeventdispatcher_glib.cpp:429
#22 0x00007ffbf0b1c014 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7fffe09b47d0, flags=...)
    at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/global/qflags.h:70
--Type <RET> for more, q to quit, c to continue without paging--
#23 0x00007ffbf0b166ab in QCoreApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/corelib/global/qflags.h:110
#24 0x00007ffbf1194002 in QGuiApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/gui/kernel/qguiapplication.cpp:1887
#25 0x00007ffbf1b67a7a in QApplication::exec() () at /usr/src/debug/qtbase-everywhere-src-6.3.1/src/widgets/kernel/qapplication.cpp:2631
#26 0x000055bfce50f16f in main(int, char**) (argc=<optimized out>, argv=0x7fffe09b49d8) at /usr/src/debug/faustlive-2.5.11/src/Utilities/main.cpp:117

[sletz]

Since this hasten in a POSIX pthread_mutex_lock function outs of FL code, I dont't think we can do a lot here.

[cbix]

Well, it is triggered by FL's TMutex::Lock() (see #8 of the backtrace) so my assumption was there might be something wrong with how that is initializing the pthread mutex, but haven't really investigated the code myself.

[cbix]

On a second system, I'm getting this assertion failure from the same code:

FaustLive: pthread_mutex_lock.c:94: ___pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
Aborted (core dumped)

This can mean for example that the mutex is not initialized properly when lock is called, so this is the responsibility of FaustLive.

[sletz]

Done here: https://github.com/grame-cncm/faust/blob/66cdb528642fdf3d607fec1b7ea7f386d7b709a4/compiler/utils/TMutex.h#L64
can you trace?

[cbix]

The issue only seems to happen on Wayland, but with both wayland and xcb (XWayland) Qt platforms (QT_QPA_PLATFORM=xcb environment variable).

[sletz]

So could we close it?

[cbix]

No, I was just providing hints to reproduce it. Obviously this may be a big issue for Wayland users. Please reopen 🙏