diff options
author | Mike Looijmans <mike.looijmans@topic.nl> | 2015-01-06 12:46:36 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2015-01-07 23:33:03 +0000 |
commit | 7b6546e0ee5561ece1c7972bb8dde7383b530eb7 (patch) | |
tree | fe99d84872fce52ebe783f231d117f668ae19b7f /meta/recipes-qt/qt4 | |
parent | 78f388e81cad5dfb6aea52da68f9b4523c88c5ad (diff) | |
download | openembedded-core-7b6546e0ee5561ece1c7972bb8dde7383b530eb7.tar.gz openembedded-core-7b6546e0ee5561ece1c7972bb8dde7383b530eb7.tar.bz2 openembedded-core-7b6546e0ee5561ece1c7972bb8dde7383b530eb7.zip |
qt4: Fix QT4 applications spamming "QWSLock::down(): Invalid argument"
If you run a QT server application, and a client in a separate process, it will
spam the log with "QWSLock::down(): Invalid argument" messages because of an old
bug in the locking code. There's a patch on the net that fixes it, which I manually
adapted by removing the commented-out debug statements.
We have been using this patch for about half a year without problems, and the QT people
apparently don't care about the bug, for which this solution has been posted in 2012.
Including this into OE core will at least save other people the trouble of having to find
and apply it for themselves.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Diffstat (limited to 'meta/recipes-qt/qt4')
-rw-r--r-- | meta/recipes-qt/qt4/qt4-4.8.6.inc | 1 | ||||
-rw-r--r-- | meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch | 98 |
2 files changed, 99 insertions, 0 deletions
diff --git a/meta/recipes-qt/qt4/qt4-4.8.6.inc b/meta/recipes-qt/qt4/qt4-4.8.6.inc index 074e82d061..a2c0688c72 100644 --- a/meta/recipes-qt/qt4/qt4-4.8.6.inc +++ b/meta/recipes-qt/qt4/qt4-4.8.6.inc @@ -26,6 +26,7 @@ SRC_URI = "http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever file://0030-aarch64_arm64_qatomic_support.patch \ file://0031-aarch64_arm64_mkspecs.patch \ file://0032-aarch64_add_header.patch \ + file://Fix-QWSLock-invalid-argument-logs.patch \ file://g++.conf \ file://linux.conf \ " diff --git a/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch b/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch new file mode 100644 index 0000000000..1f5f00f716 --- /dev/null +++ b/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch @@ -0,0 +1,98 @@ +From 52c34001bad85c3032618070b1d6b2a3c6880715 Mon Sep 17 00:00:00 2001 +From: Neil Jerram <n...@ossau.homelinux.net> +Date: Thu, 8 Nov 2012 08:18:32 +0000 +Subject: [PATCH] Fix QWSLock "invalid argument" logs + +There was no known actual problem associated with these logs, but they +were spamming the log, so I thought it worth trying to understand and +fix them. + +The confusion is that there are two different ways of creating QWSLock +objects. "QWSLock()" creates an object that creates a new set of +semaphores, whereas "QWSLock(id)" creates an object that aliases the +existing set of semaphores with ID id. What seems to happen is that +each application creates a semaphore set scoped to that +application (QWSDisplay::Data::clientLock in qapplication_qws.cpp), +then this semaphore set is passed by complex means to +places (QWSClientPrivate and QWSMemorySurface) that use the semaphores +for a short period and then delete their QWSLock objects. + +The problem was that the QWSLock destructor always destroyed the +semaphore set, even when that QWSLock hadn't create the semaphores +itself, hence making the semaphores invalid for other QWSLock objects +still referencing the same set. + +Clearly a QWSLock object shouldn't destroy the semaphore set if it +didn't create it itself, and that is confirmed by the fact that one of +the implementations inside QWSLock already implements this logic, with +the 'owned' flag. The fix is to implement this for the #ifndef +QT_POSIX_IPC case - which is what is used in QtMoko - just as is +already implemented for the #ifdef QT_POSIX_IPC case. + +Original patch can be found here: + http://www.mail-archive.com/community@lists.openmoko.org/msg65512.html + +Upstream-Status: Submitted + +Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> + (Removed the commented-out debug statements from the original patch.) + +--- + +diff --git a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp +index 9914a24..1055785 100644 +--- a/src/gui/embedded/qwslock.cpp ++++ b/src/gui/embedded/qwslock.cpp +@@ -83,9 +83,12 @@ QWSLock::QWSLock(int id) : semId(id) + QWSSignalHandler::instance()->addWSLock(this); + #endif + ++ owned = false; ++ + #ifndef QT_POSIX_IPC + if (semId == -1) { + semId = semget(IPC_PRIVATE, 3, IPC_CREAT | 0666); ++ owned = true; + if (semId == -1) { + perror("QWSLock::QWSLock"); + qFatal("Unable to create semaphore"); +@@ -100,7 +104,6 @@ QWSLock::QWSLock(int id) : semId(id) + } + #else + sems[0] = sems[1] = sems[2] = SEM_FAILED; +- owned = false; + + if (semId == -1) { + // ### generate really unique IDs +@@ -134,9 +137,11 @@ QWSLock::~QWSLock() + + if (semId != -1) { + #ifndef QT_POSIX_IPC +- qt_semun semval; +- semval.val = 0; +- semctl(semId, 0, IPC_RMID, semval); ++ if (owned) { ++ qt_semun semval; ++ semval.val = 0; ++ semctl(semId, 0, IPC_RMID, semval); ++ } + semId = -1; + #else + // emulate the SEM_UNDO behavior for the BackingStore lock +diff --git a/src/gui/embedded/qwslock_p.h b/src/gui/embedded/qwslock_p.h +index d324e4f..d867d20 100644 +--- a/src/gui/embedded/qwslock_p.h ++++ b/src/gui/embedded/qwslock_p.h +@@ -86,8 +86,8 @@ private: + int lockCount[2]; + #ifdef QT_POSIX_IPC + sem_t *sems[3]; +- bool owned; + #endif ++ bool owned; + }; + + QT_END_NAMESPACE + +-- +1.7.10.4 |