Drop the read and write permissions for group and other users in the
system.
Change-Id: I8fc753f09126651af3fb82df3049050f0b14e876
Reviewed-by: Richard J. Moore <rich@kde.org>
This test runs fine almost all of the time on systems with 1
processor, which were the norm when the test was written and are still
the way that the Qt Continuous Integration system works as of
today. But it falls flatly on multi-processor systems.
The root of the problem is that QSystemSemaphore recreates the
semaphore if it disappears underneath it. However, the recreation
process is not thread-safe at all: if two threads race to recreate it,
weird things might happen. strace on Linux shows that a thread got
stuck trying to acquire the semaphore:
<... nanosleep resumed> NULL) = 0
stat("/tmp/qipc_systemsem_market5c9f73af73334ffe350c60ec076e5744db0ecda3", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
stat("/tmp/qipc_systemsem_market5c9f73af73334ffe350c60ec076e5744db0ecda3", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
semget(0x51001388, 1, IPC_CREAT|IPC_EXCL|0600) = -1 EEXIST (File exists)
semget(0x51001388, 1, IPC_CREAT|0600) = 114786308
semop(114786308, {{0, -1, SEM_UNDO}}, 1 <unfinished ...>
This problem does not happen if the creation and destruction of the
QSharedMemory (which uses QSystemSemaphore) does not race with other
threads or processes attaching and detaching. For the threads test
it's easy. For the processes, we use stdin and stdout as a
communication channel.
Change-Id: Ie11b135431d4abfc59234654848b67f622eb03c9
Reviewed-by: Richard J. Moore <rich@kde.org>
As the script dependency for that autotest is not really needed it should
be moved to qtbase.
Task-number: QTBUG-27706
Change-Id: Ieda8b2182a20a77f53a0be9878e82e3236c79c2b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Frederik Gladhorn
Pasi Petäjäjärvi
Sergio Ahumada
Thiago Macieira
Oliver Wolff