summaryrefslogtreecommitdiffstats
path: root/meta
diff options
context:
space:
mode:
authorMike Looijmans <mike.looijmans@topic.nl>2015-01-06 12:46:36 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2015-01-07 23:35:07 +0000
commitd1b523e7dd55b11d1b02904a83a0464b95616c07 (patch)
tree2ea84016462173f74f3bd33b87907fe7864c5cc0 /meta
parentfca3bc561ceaa485bae6140aadd32c84f75d74f7 (diff)
downloadpoky-d1b523e7dd55b11d1b02904a83a0464b95616c07.tar.gz
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. (From OE-Core rev: 7b6546e0ee5561ece1c7972bb8dde7383b530eb7) Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta')
-rw-r--r--meta/recipes-qt/qt4/qt4-4.8.6.inc1
-rw-r--r--meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch98
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
26 file://0030-aarch64_arm64_qatomic_support.patch \ 26 file://0030-aarch64_arm64_qatomic_support.patch \
27 file://0031-aarch64_arm64_mkspecs.patch \ 27 file://0031-aarch64_arm64_mkspecs.patch \
28 file://0032-aarch64_add_header.patch \ 28 file://0032-aarch64_add_header.patch \
29 file://Fix-QWSLock-invalid-argument-logs.patch \
29 file://g++.conf \ 30 file://g++.conf \
30 file://linux.conf \ 31 file://linux.conf \
31 " 32 "
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 @@
1From 52c34001bad85c3032618070b1d6b2a3c6880715 Mon Sep 17 00:00:00 2001
2From: Neil Jerram <n...@ossau.homelinux.net>
3Date: Thu, 8 Nov 2012 08:18:32 +0000
4Subject: [PATCH] Fix QWSLock "invalid argument" logs
5
6There was no known actual problem associated with these logs, but they
7were spamming the log, so I thought it worth trying to understand and
8fix them.
9
10The confusion is that there are two different ways of creating QWSLock
11objects. "QWSLock()" creates an object that creates a new set of
12semaphores, whereas "QWSLock(id)" creates an object that aliases the
13existing set of semaphores with ID id. What seems to happen is that
14each application creates a semaphore set scoped to that
15application (QWSDisplay::Data::clientLock in qapplication_qws.cpp),
16then this semaphore set is passed by complex means to
17places (QWSClientPrivate and QWSMemorySurface) that use the semaphores
18for a short period and then delete their QWSLock objects.
19
20The problem was that the QWSLock destructor always destroyed the
21semaphore set, even when that QWSLock hadn't create the semaphores
22itself, hence making the semaphores invalid for other QWSLock objects
23still referencing the same set.
24
25Clearly a QWSLock object shouldn't destroy the semaphore set if it
26didn't create it itself, and that is confirmed by the fact that one of
27the implementations inside QWSLock already implements this logic, with
28the 'owned' flag. The fix is to implement this for the #ifndef
29QT_POSIX_IPC case - which is what is used in QtMoko - just as is
30already implemented for the #ifdef QT_POSIX_IPC case.
31
32Original patch can be found here:
33 http://www.mail-archive.com/community@lists.openmoko.org/msg65512.html
34
35Upstream-Status: Submitted
36
37Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
38 (Removed the commented-out debug statements from the original patch.)
39
40---
41
42diff --git a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp
43index 9914a24..1055785 100644
44--- a/src/gui/embedded/qwslock.cpp
45+++ b/src/gui/embedded/qwslock.cpp
46@@ -83,9 +83,12 @@ QWSLock::QWSLock(int id) : semId(id)
47 QWSSignalHandler::instance()->addWSLock(this);
48 #endif
49
50+ owned = false;
51+
52 #ifndef QT_POSIX_IPC
53 if (semId == -1) {
54 semId = semget(IPC_PRIVATE, 3, IPC_CREAT | 0666);
55+ owned = true;
56 if (semId == -1) {
57 perror("QWSLock::QWSLock");
58 qFatal("Unable to create semaphore");
59@@ -100,7 +104,6 @@ QWSLock::QWSLock(int id) : semId(id)
60 }
61 #else
62 sems[0] = sems[1] = sems[2] = SEM_FAILED;
63- owned = false;
64
65 if (semId == -1) {
66 // ### generate really unique IDs
67@@ -134,9 +137,11 @@ QWSLock::~QWSLock()
68
69 if (semId != -1) {
70 #ifndef QT_POSIX_IPC
71- qt_semun semval;
72- semval.val = 0;
73- semctl(semId, 0, IPC_RMID, semval);
74+ if (owned) {
75+ qt_semun semval;
76+ semval.val = 0;
77+ semctl(semId, 0, IPC_RMID, semval);
78+ }
79 semId = -1;
80 #else
81 // emulate the SEM_UNDO behavior for the BackingStore lock
82diff --git a/src/gui/embedded/qwslock_p.h b/src/gui/embedded/qwslock_p.h
83index d324e4f..d867d20 100644
84--- a/src/gui/embedded/qwslock_p.h
85+++ b/src/gui/embedded/qwslock_p.h
86@@ -86,8 +86,8 @@ private:
87 int lockCount[2];
88 #ifdef QT_POSIX_IPC
89 sem_t *sems[3];
90- bool owned;
91 #endif
92+ bool owned;
93 };
94
95 QT_END_NAMESPACE
96
97--
981.7.10.4