oosplash.bin keeps on running after LO shutdown. This can be seen here by running the following tests: forms/qa/complex/forms configmgr/qa/unoapi sd/qa/unoapi ucb/complex/ucb ucb/qa/unoapi qadevOOo/qa/unoapi chart2/qa/unoapi unotools/qa/complex/tempfile qadevOOo/qa/unoapi starmath/qa/unoapi by executing: export OOO_SUBSEQUENT_TESTS=TRUE cd $TESTDIR dmake These tests will be disabled for now in subsequenttests. They should be reenabled once this is fixed.
Assign -> mmeeks Whiteboard -> complextest unoapitest blocking 35690
All affected tests disable for now with commits: base = [master 1538b1b] calc = [master 2856904] components = [master b6930bc] impress = [master 15c51a6] libs-core = [master cec3292] libs-gui = [master ab066b5] testing = [master aaa1707] writer = [master 0c729a6] with message "fd#35693: disable hangin subsequenttests (complex and unoapi tests)"
I had to additionally disable: dbaccess/qa/unoapi linguistic/qa/unoapi as they would hang too sometimes.
Here is a backtrace from the main thread: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x00007ff00c52ec6c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:259 #2 0x00007ff00b76e55f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007ff00b76ea5f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #4 0x00007ff00b76eae4 in xcb_writev () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #5 0x00007ff00c229247 in _XSend () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #6 0x00007ff00c229605 in _XFlush () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #7 0x00007ff00c208c2a in XFlush () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #8 0x0000000000405b9e in process_events () at splashx.c:578 #9 0x0000000000405d53 in splash_draw_progress (progress=55) at splashx.c:615 #10 0x0000000000407d53 in sal_main_with_args (argc=7, argv=0x7fff8ee3fd38) at start.c:963 #11 0x0000000000407b56 in main (argc=7, argv=0x7fff8ee3fd38) at start.c:878 Just commenting out the splash_draw_progress() call at start.c:963 removes the deadlock, however this seems _not_ to be the reason for the blocking unittests as soffice stays around even then. => removing block of 35690 The second thread blocked in rtl_cache_wsupdate_wait, however I still havent found out how the conditions and mutexes from g_chache_list interfere with the some condition deep in X.
resolving as NOTOURBUG. Reiterating observations with a clear mind showed that the bug never showed up when running the test in a vncserver session => this os a bug of my X11 server implementation.