Commit 643ad3e [Fix race in LoadInBackground() handling] causes abort on entering Watch Recordings

[Lawrence Rust <lvr@…>]

Using a debug build of Qt, entering the watch recordings menu, mythfrontend aborts with this log:

2012-08-07 11:40:41.754876 C  Received Aborted
QMutex::lock: Deadlock detected in thread 2985436960 
Aborted (core dumped)

Backtrace:

Program terminated with signal 6, Aborted.
#0  0xb76e9424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb76e9424 in __kernel_vsyscall ()
#1  0xb249ae71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb249e34e in abort () at abort.c:92
#3  0xb277a30f in qt_message_output (msgType=QtFatalMsg, 
    buf=0xa561088 "ASSERT failure in QMutex::unlock(): \"A mutex must be unlocked in the same thread that locked it.\", file thread/qmutex.cpp, line 370")
    at global/qglobal.cpp:2259
#4  0xb277a48e in qt_message (msgType=QtFatalMsg, 
    msg=0xb28e6940 "ASSERT failure in %s: \"%s\", file %s, line %d", 
    ap=0xa2ca9234 "\261|\216\262 }\216\262d|\216\262r\001")
    at global/qglobal.cpp:2305
#5  0xb277a549 in qFatal (
    msg=0xb28e6940 "ASSERT failure in %s: \"%s\", file %s, line %d")
    at global/qglobal.cpp:2488
#6  0xb277a587 in qt_assert_x (where=0xb28e7cb1 "QMutex::unlock()", 
    what=0xb28e7d20 "A mutex must be unlocked in the same thread that locked it.", file=0xb28e7c64 "thread/qmutex.cpp", line=370) at global/qglobal.cpp:2012
#7  0xb277e2df in QMutex::unlock (this=0xa5fb7f8) at thread/qmutex.cpp:369
#8  0xb5b8a11f in ScreenLoadTask::run (this=0xa2e0de0) at mythscreentype.cpp:33
#9  0xb5d28a06 in MPoolThread::run (this=0xa600910) at mthreadpool.cpp:87
#10 0xb5d25f74 in MThreadInternal::run (this=0xa1afd00) at mthread.cpp:79
#11 0xb27832e0 in QThreadPrivate::start (arg=0xa1afd00)
    at thread/qthread_unix.cpp:266
#12 0xb2705e99 in start_thread (arg=0xa2ca9b70) at pthread_create.c:304
#13 0xb25419ee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Appears that the new mutex is being unlocked by a thread other than the one that locked it.

[danielk]

This didn't strike me as a proper QMutex requirement and it is missing from the documentation. So I looked at the sources and it seems this assert exists in Qt 4.3 but the bug has been removed in Qt 4.8.1.

Please update to Qt 4.8.1 or later and reopen if this re-occurs.

[Lawrence Rust <lvr@…>]

You're using the wrong locking mechanism;, it should be a semaphore. Qt is warning you that Mutex semantics imply thread ownership.

I have no intention of updating to Qt 4.8.1 as it has a myriad of other bugs that cause problems. Furthermore, Ubuntu 11.04 ships with 4.7.2 and a number of apps that I use depend on that.

Bye...

[danielk]

We're just using a QMutex as a binary semaphore here, there is nothing in the Qt documentation I looked at implying additional restrictions on QMutex wrt to thread ownership + it appears this inconsistency is corrected in later Qt versions + it doesn't have any nasty side effects unless you use a debug build. But if you want to submit a QSemaphore patch I'll review it.

[danielk]

Alternatively, if you can point me to some documentation showing Qt 4.6 or later requires a QMutex to only be used in a single thread. I don't want to change code for an errant debugging macro, but if there is a real limitation in a supported Qt version that's a wholly different matter.

[danielk]

Bah, nevermind -- I found it.. I'll port to QSemaphore. Sorry about the noise.

[Daniel Kristjansson <danielk@…>]

In 8e3bc060402cb1be48f7e1d2dd605811ca255096/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available