Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#10981 closed Bug Report - General (fixed)

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

Reported by: Lawrence Rust <lvr@…> Owned by: Daniel Kristjansson <danielk@…>
Priority: minor Milestone: 0.26
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Change History (7)

comment:1 Changed 7 years ago by danielk

Resolution: Upstream Bug
Status: newclosed

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.

comment:2 Changed 7 years ago by 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...

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by danielk

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

comment:6 Changed 7 years ago by Daniel Kristjansson <danielk@…>

Owner: set to Daniel Kristjansson <danielk@…>
Resolution: Upstream Bugfixed

In 8e3bc060402cb1be48f7e1d2dd605811ca255096/mythtv:

Fixes #10981. Refs #10928. Convert QMutex to QSemaphore.

Since m_LoadLock is locked in the UI thread and unlocked in
the worker thread it needs to use a QSemaphore instead of
a QMutex. Thanks go to Lawrence Rust for discovering the
issue.

comment:7 Changed 7 years ago by Raymond Wagner

Milestone: unknown0.26
Note: See TracTickets for help on using tickets.