To minimize code duplication, move the socket notifier deletion to the
closeChannel() function, where the pipe descriptor will be closed.
Change-Id: If75ba1c955c706ae6e2b3d9f53f7a25e4aa32fa7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Otherwise, the user may receive the readyRead() signal just before
started().
Change-Id: I8d6fd18fdfcef0580a3e609100198b03b18b1175
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
The completion of the child process can take place asynchronously or in
one of the waitFor...() functions. In both cases, we used the same
handler (_q_processDied()), which caused several problems:
a. technically, waitForReadyRead() should have taken into account the
result of the calls to _q_canRead...() slots inside the
_q_processDied() function:
- the user calls waitForReadyRead();
- forkfd descriptor becomes signaled, while a grandchild
process is still alive;
- as readyRead() signal has not been emitted, _q_processDied()
is called;
- the grandchild process writes to stdout pipe;
- now data arrives, and _q_processDied() will collect it, but
won't report it.
b. we had a bug with recursions on Unix:
- death notification comes asynchronously;
- waitForDeadChild() closes forkfd;
- _q_canRead...() emits readyRead();
- a slot connected to readyRead() calls waitForFinished();
- waitForFinished() hangs (forkfd == -1).
c. for blocking functions, drainOutputPipes() was called twice on
Windows.
By introducing a new processFinished() function, we leave the read
operations in the _q_processDied() slot, while the process completion
code is guaranteed to run only once.
Change-Id: I5f9d09bc68a058169de4d9e490b48fc0b35e94cd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
There is no reason to have the startup notifier and the death notifier
be active at the same time, as the former will detect death as well.
Previously, these notifiers were racing, but _q_processDied() ordered
signals by calling _q_startupNotification() manually. Thus, the
started()/finished() sequence was always emitted if the child process
was killed anywhere. Now this ordering is simply not necessary anymore.
This makes it possible to reuse the startup notifier for death
notification.
Change-Id: I5ebed9b5f28b19fe56c80498977a3b21be9288fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
[ChangeLog][QtCore][QProcess] Added support for QProcess::MergedChannels
mode with startDetached().
Change-Id: I953ad2063322015332269522a297f8e2842e438c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
We have the same channel forwarding, redirecting, and merging rules for
all platforms. This makes it possible to introduce the openChannels()
function, which consolidates the logic and performs high-level general
processing of the channels configuration properties.
Change-Id: Id3574fc42a56829328369b6a1a6ec9c95fce8eca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
By using new QSocketNotifier API, we can avoid unnecessarily enabling
the notifier right before turning it off again.
Change-Id: Ie0dea00251e9885653677c495dfc5abaaa4db1c7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
The child process inherits a standard handle of the main process in
such cases:
stdin - inputChannelMode == QProcess::ForwardedInputChannel,
stdout - processChannelMode == QProcess::ForwardedChannels ||
processChannelMode == QProcess::ForwardedOutputChannel,
stderr - processChannelMode == QProcess::ForwardedChannels ||
processChannelMode == QProcess::ForwardedErrorChannel ||
processChannelMode == QProcess::MergedChannels
For these combinations we should not create pipes and notifiers as
they would not be used.
Change-Id: I8e3836e4d840a40b338c85c54645539ebcaab3f6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
It makes no sense to poll the I/O pipes if we didn't get a start-up
notification yet. And in fact, all waitFor...() functions except
waitForReadyRead() did already explicitly wait for process startup
completion. So fix that one up, and remove the handling of 'Starting'
state from the I/O loops.
Change-Id: Ibb7eb7c768bef3f9b6c54009c73b91775570102c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Replacing QElapsedTimer with QDeadlineTimer simplifies the code in
waiting functions, which also improves readability.
Change-Id: I56aedd356b547b6735ed0985dc81be706e292437
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Both on Unix and Windows, _q_processDied() unconditionally releases all
resources associated with the terminated child process, resets QProcess
to the initial state, and emits finished() signal. Thus, we can omit
reporting success, which also eliminates the related checks from
callers.
Change-Id: I40e32d1a9ccc8d488be6badba934355d734a8abd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
QProcessPrivate::tryReadFromChannel() returns 'true' only if we emitted
readyRead() signal on the current read channel. Thus, these additional
checks are unnecessary.
Change-Id: Id98620cd08ee8808f60539c009986b869e517ef0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
this implements a suggestion made by a comment that got lost in
028ddf363: as explained in 97645478's commit message, we were forcing
use of fork() because we couldn't be sure that the code in a custom
setupChildProcess() did not rely on pthread_atfork() callbacks being
called.
however, that in turn was inconsistent with the default behavior, and
made customizing QProcess mutually exclusive with benefitting from
forkfd().
use the opportunity presented by changing the method of modifying child
process behavior to also change this.
this also amends 4e2f4670, as most of the now deleted comment in fact
related to the use of vfork semantics, which we don't do anymore.
[ChangeLog][Important Behavior Changes][QtCore][QProcess][Unix]
pthread_atfork() callbacks are consistently not invoked on reasonably
recent Linux and FreeBSD systems any more. This was already the case in
later Qt 5 releases, unless setupChildProcess() was overridden.
Change-Id: Icb239e4d2c705bf4665589469022a521267f7db5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It can happen under unspecified conditions, see relevant ticket.
Task-number: QTBUG-86285
Pick-to: 5.15
Change-Id: I1f77bf0061a0faaa60283bb93fc3d82031247d54
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is not used in public API any more since
0f8848b7e25e4d8fb9265ff6e0aa31946addd741.
Replace by an internal Windows-specific Q_PROCESS_INFORMATION typedef.
Change-Id: Ia6dcc83ca667c40ac5d678c00d143c09d650e42a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Our CI cross-compiling arm qemu builds have issues in tests that use
QProcess, due to user-space qemu seemingly not supporting pidfds
properly.
Add a 'forkfd_pidfd' configure.json feature, which can be manually
disabled when configuring Qt, causing QProcess to do a regular fork
instead of using the new pidfd kernel feature.
This will help us avoid the regression of multiple tests failing on
the new Ubuntu 20.04 CI host images when they are run via qemu.
Task-number: QTBUG-86285
Task-number: QTBUG-86187
Task-number: QTBUG-86198
Change-Id: Ib2209d7e95126e0fb738bf59e39070d5a62c482f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][Source-Incompatible Changes] QProcess::setupChildProcess()
was removed. To execute code in a child process, use
QProcess::setChildProcessModifier()
[ChangeLog][QtCore][QProcess] Added setChildProcessModifier() function
with which one can provide code to be run in the Unix child process
between fork() and execve(). With this function, it is no longer
necessary to derive from QProcess in order to execute actions in the
child process.
Another reason is that we can tell whether the std::function carries a
valid target much more easily than we can tell whether QProcess was
overridden.
The setupChildProcess() virtual function does not need to be marked
final, since no overrider could ever return an inaccessible private
class. This also makes sure the error presented to the user is about the
return type, not about attempting to override a final.
Clang:
error: virtual function 'f' has a different return type ('void') than the function it overrides (which has return type 'QProcess::Use_setChildProcessModifier_Instead')
GCC:
error: conflicting return type specified for 'virtual void MyProcess::setupChildProcess()'
note: overridden function is 'virtual QProcess::Use_setChildProcessModifier_Instead QProcess::setupChildProcess()'
ICC:
error: return type is neither identical to nor covariant with return type "QProcess::Use_setChildProcessModifier_Instead" of overridden virtual function "QProcess::setupChildProcess"
MSVC is not relevant since it doesn't compile to Unix.
Change-Id: Ia8b65350cd5d49debca9fffd15f801161363aea7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This will never work, not unless libc implements it
themselves, since the child process is not allowed to return
from the function that does the vfork(), as subsequent use
of the stack would trash the frozen parent's return address,
and in our case that's syscall(). Instead, we may add a
vforkfd() function that takes a callback function that will
be called in that context, like the glibc clone(3) wrapper
does.
Pick-to: 5.15
Change-Id: I1dba29bc0f454df09ca1fffd161800b453c00593
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The pre-existing overload passes an int, but this can mean the
descriptor gets truncated in compilations where the descriptor
is 64-bit.
The old overload with int is visible when querying the metaobject system
so string-based connects still work as before, and connecting to it will
produce a deprecation warning in the output.
At the same time the PMF-based connect will, on recompile, pick the
QSocketDescriptor overload. As an added improvement it also comes with
the notification type, removing the need for separate slots where the
code would be mostly shared anyway.
The QSocketDescriptor type can be implicitly converted to and from
qintptr to ensure existing code still compiles. It can also be
constructed from Qt::HANDLE on Windows.
In this same patch I also update the existing string-based connects in
this module, which then includes updating the parameters for some slots
as well.
[ChangeLog][QtCore][QSocketNotifier] Added
QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type).
This replaces the activated(int) signal which in 64-bit environments
could truncate the socket descriptor. If you use "activated" with the
string-based connect() then you need to update the parameter type of the
signal and slot if it had one. If you use it with the pointer to member
function based connect() then all you need to do is update your slot's
parameter type if it has one. If you need to compile your source code
with multiple versions of Qt then connect() to this function using
pointer to member function and update the slot's parameter type if
needed.
Task-number: QTBUG-70441
Change-Id: Ic43d6bc4c5bcb4040867b2ffad8d36fb01eed8af
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
... when we are not using the FFD_USE_FORK flag. We use the FFD_USE_FORK
flag when we have user code to run in setupChildProcess(). This code is
enabled for all Unix, but forkfd() honors this flag only on Linux >=
5.4.
See the commit adding the flag for more information on what the flag
does and see the comment in this commit on why it's safe to use it.
Fixes: QTBUG-17331
Change-Id: I1bee3bc466a04f19bd6efffd15f448cb23ce1e91
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
If the user derived from QProcess, it's likely to override the
setupChildProcess() virtual. Unlike fork(), the system calls for
enhenced functionality (FreeBSD pdfork() and Linux's clone()) won't call
pthread_atfork() callbacks and the environment in the child process
could be inconsistent. Qt's own code is safe, but we can't make the same
statement about users' code.
So we err on the safe side for correctness and run the old, less safe
implementation (thread-unsafe, subject to hijacking of the signal
handler, etc.).
Change-Id: Ia2aa807ffa8a4c798425fffd15d9703bd03f6f09
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QObjectPrivate::threadData used to be a QThreadData *, and was
read and written from multiple threads without proper synchronization.
As an example, it was read from QCoreApplication::postEvent and
written from QObject::moveToThread, therefore causing UB.
Port threadData to a proper atomic, removing the races. Fix all usage
points.
In general, QObject is documented to be simply reentrant,
not thread-safe, and certain bits (e.g. timers, moveToThread)
are not even reentrant. The reasoning therefore is that a given
QObject's threadData is not supposed to be touched by multiple
threads without some synchronization happening elsewhere, and
therefore relaxed loads should be sufficient.
As drive-by change: refactor QCoreApplication::postEvent.
It was particularly subtle, because it had a loop using a volatile
to cope with the possibility of the receiver object switching thread
while we tried to lock its thread's event queue.
However, volatile does not achieve any synchronization, so drop it,
and refactor the algorithm using better locking primitives.
Put this algorithm in a common place, and also reuse it from
removePostedEvents, which was lacking any synchronization.
Change-Id: Icc755f7eb418ff54b33db4bdd87fd8eaf4e82c7a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... except four instances in QCoreApplication that would conflict with
another change.
Replace a locally-defined MutexUnlocker with a call to unlock() +
qScopedGuard'ed lock() to avoid having to spell out the locker type
while we can't depend on C++17 CTAD, yet.
In QSettings, move the new mutex locker into and out of
initDefaultPaths(), such as is idiomatic for std::unique_lock, but
wasn't possible with QMutexLocker (which is not movable).
Change-Id: I23056e13ecaa76159db583c7dccc6e05715e0788
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The mutex is only protecting 'nameMap'. Proof: it's only defined on
platforms on which there is a 'nameMap'. Also, nothing else is
mutable, so no lazy init going on here.
So, drop all the mutex protection, except where we access 'nameMap',
and draw the mutex as close as possible to the nameMap uses, iow: copy
ctor, prepareName() and nameToString().
As a consequence, the old (Ordered)MutexLocker class only needs to be
defined on Unix.
Change-Id: Ic969313bc48ad7ebf24c5dca7fd48359956b048d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The old code used the implicit conversions from QAtomicPointer<T> to T*
and vice versa. The semantics of these differ from the ones std::atomic
uses, so we're going to deprecate these, like we did for load() and
store(), too.
This patch fixex some users of these APIs before we deprecate them.
Change-Id: I0a88bb1c359392538bb64b511bfc62381a56a468
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add it to configure.json and replace all occurrences of QT_NO_THREAD
with QT_CONFIG(thread). Add conditions for other features that depend
on thread support. Remove conditions where we can use the QMutex and
QThreadStorage stubs.
Change-Id: I284e5d794fda9a4c6f4a1ab29e55aa686272a0eb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The channel pipes are only set up if the channel's type is
Redirect. Fix the conditions accordingly.
This amends commit 7ad55ca6.
Change-Id: Ie8a800fbe2bf9f5f6709b14ba03133b80e9b4bef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Conflicts:
examples/examples.pro
qmake/library/qmakebuiltins.cpp
src/corelib/global/qglobal.cpp
Re-apply b525ec2 to qrandom.cpp(code movement in 030782e)
src/corelib/global/qnamespace.qdoc
src/corelib/global/qrandom.cpp
src/gui/kernel/qwindow.cpp
Re-apply a3d59c7 to QWindowPrivate::setVisible() (code movement in d7a9e08)
src/network/ssl/qsslkey_openssl.cpp
src/plugins/platforms/android/androidjniinput.cpp
src/plugins/platforms/xcb/qxcbconnection.cpp
src/plugins/platforms/xcb/qxcbconnection_xi2.cpp
src/widgets/widgets/qmenu.cpp
tests/auto/widgets/kernel/qwidget_window/tst_qwidget_window.cpp
Change-Id: If7ab427804408877a93cbe02079fca58e568bfd3
Calling QCoreApplication::processEvents() from a slot connected to the
readyRead() signal might cause desynchronization in the waitForXXX()
loop, if the process has been finished during the event processing.
This results in unnecessary timeouts and causes waitForFinished() to
fail unexpectedly.
So, a proposed solution is to check the state on each iteration of the
loop, as Windows implementation does.
Given issue is tested by tst_QProcess::processEventsInAReadyReadSlot()
which was unstable in CI.
Task-number: QTBUG-62584
Change-Id: I7438cf67b0163bbf49314008a9dc660c0977fb7b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In theory, there's nothing wrong with having it in the child process. In
practice, we've found that strerror/malloc can hang: if an application-
wide lock was held by another thread before fork(), the child process
could wait forever for an unlocking that will not happen (no threads
running). See https://sourceware.org/bugzilla/show_bug.cgi?id=19431
As an added bonus, we now use qt_error_string(), which may produce
slightly different text from strerror.
[ChangeLog][QtCore][QProcess] Added a workaround for a rare race-
condition bug in some C libraries that caused the child process started
by QProcess to hang after trying to launch a non-existent executable or
change to a non-existent directory.
Task-number: QTBUG-61634
Change-Id: I1eba2b016de74620bfc8fffd14cbce4b9f9af69b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
[ChangeLog][QtCore][QProcess] Added support for standard channel
redirection using setStandard{Input|Output|Error}File to
QProcess::startDetached.
Task-number: QTBUG-2058
Task-number: QTBUG-37656
Change-Id: Iafb9bd7899f752d0305e3410ad4dcb7ef598dc79
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The motivation for this change is to make it simple to pass a
correctly sorted environment block to Win32 CreateProcess(). It is
also nice in other contexts that the environment variables are
sorted. The change is made for all platforms. This keeps it simple and
the only ill effect is slightly slower lookups.
Concerning the environment block passed to Win32 CreateProcess:
The environment block that is passed to CreateProcess() must be sorted
case-insensitively and without regard to locale. See
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682009(v=vs.85).aspx
The need for sorting the environment block is also mentioned in the
CreateProcess() documentation, but with less details:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
Task-number: QTBUG-61315
Change-Id: Ie1edd443301de79cf5f699d45beab01b7c0f9de3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also use auto for iterators to vars. This is a small refactoring in
preparation for changing type of vars to QMap.
Task-number: QTBUG-61315
Change-Id: I5731d7916b6f54a0da5be2da378c09a7688bd870
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This fixes a regression introduced in ff19ebcc
Task-number: QTBUG-60046
Change-Id: I47c357433b25f07011a7a3a64d3150591785b206
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Starting a detached process with a custom process environment can now be
achieved by:
QProcess p;
p.setProgram("foo");
p.setProcessEnvironment(myEnv);
p.startDetached();
[ChangeLog][QtCore][QProcess] Added the ability to set a custom process
environment for detached processes.
Task-number: QTBUG-2284
Change-Id: I49406dffb64fa2aed41ea05cb271bd42eeabb729
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The three static QProcess::startDetached overloads support a limited number of
features: program, arguments and working directory. To support more features of
QProcess (without adding a plethora of overloads) we add a non-static method
startDetached that can be used as follows:
QProcess p;
p.setProgram("cat");
p.setArguments("meow");
p.setWorkingDirectory("/tmp");
if (!p.startDetached())
qWarning("Cannot start process.");
We plan to add support for nativeArguments, processEnvironment,
standard{Output|Error}File and maybe more in subsequent commits.
[ChangeLog][QtCore][QProcess] Added non-static QProcess::startDetached
to support more features for detached processes.
Task-number: QTBUG-2058
Task-number: QTBUG-2284
Task-number: QTBUG-37656
Task-number: QTBUG-52405
Task-number: QTBUG-57687
Change-Id: If6fdd57ecb28cd13aa5fff566216a4177f81d339
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Replace all QT_NO_PROCESS with QT_CONFIG(process), define it in
qconfig-bootstrapped.h, add QT_REQUIRE_CONFIG(process) to the qprocess
headers, exclude the sources from compilation when switched off, guard
header inclusions in places where compilation without QProcess seems
supported, drop some unused includes, and fix some tests that were
apparently designed to work with QT_NO_PROCESS but failed to.
Change-Id: Ieceea2504dea6fdf43b81c7c6b65c547b01b9714
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
All Apple Platforms have public API to get the environment; there is no
reason to exclude it from the UIKit subset. It can be useful for
debugging in Xcode, in particular. Furthermore, VxWorks appears to have
support for the Unix environment API, so don't exclude it either.
[ChangeLog][QtCore] QProcessEnvironment is now available on iOS, tvOS,
watchOS, and VxWorks
Change-Id: Ife3745f9b0a588de521a714b4273c5c08eeef286
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This decouples QProcess and QProcessEnvironment, since the latter may
actually be available on platforms where the former is not.
Change-Id: I3dc799ffdf94486b64143ed01a369897fff44a96
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Slims down QCFString and leaves only one implementation of converting
back and forth between CF/NS strings and QStrings.
Change-Id: I068568ffa25e6f4f6d6c99dcf47078b7a8e70e10
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
