When in a unity-build GCC 13 sees the implementation of
forkfd_wait4(), called dfrom forkfd_wait(), it can prove that there
are paths that do not initialize *info: Those paths are the returns
following fcntl() in system_forkfs_wait() in forkd_linux.c and read()
in forkfd_wait4().
To work around the issue and unbreak unity-builds, initialize info = {}.
Task-number: QTBUG-119081
Pick-to: 6.5
Change-Id: I1b3504e7f83c766ebccc851233d4c3e677bf2acd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 635774fc324f079a41e2cecbcfdb700bf171ab6c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
And take the opportunity to clarify what the QtVforkSafe namespace is
doing. Amends commit e71c226d6f188abd811b28d3cb7529343f52d61f.
Change-Id: I443cf0c8a76243eead33fffd1767f3fa390a7cdd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
(cherry picked from commit c4a0a76deca0bc5082fb561004bc0d29a8de9978)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
On FreeBSD, the environ variable doesn't come from libc, but is instead
inserted during linking. See ccf74b592809e0c5a613eff27d6431a4c659e368
(5.6) for more information.
But instead of allowing undefined symbols in QtCore, let's use a weakref
to environ so this one symbol is allowed to be undefined. It won't be,
but the linker doesn't know.
FreeBSD appears to be the only BSD to require this. We used to apply the
same linker option to OpenBSD in Qt 5, but neither the OpenBSD or nor
the NetBSD ports trees[1][2] carry a patch for this, so I don't think
it's necessary.
[1] https://github.com/openbsd/ports/tree/master/x11/qt6/qtbase/patches
[2] https://github.com/NetBSD/pkgsrc/tree/trunk/x11/qt6-qtbase/patches
Change-Id: I63b988479db546dabffcfffd17661c839014771a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 166e7922695e9b145e0ce33e3674a1716021a1e3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This amends commit f9c87cfd44bcf4b90cb45354252ef19f647b0469 to reset the
signal block mask too, not just the signal handlers. For this, SIGPIPE
is not treated specially.
Change-Id: Ib5ce7a497e034ebabb2cfffd17627289614bf315
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 062b2ac71bac1e0449eff7f8f02cb0020ad39991)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
I've investigated the functions we call in the child side of a vfork()
for implementations that do more than simply place the system
call. Where wrappers exist, they are usually related to handling of Unix
signals or PThread cancellation. The implementations investigated are:
- Bionic (Android)
- FreeBSD
- glibc (Linux)
- MUSL (Linux)
- NetBSD
- OpenBSD
Relating to thread cancellation, NetBSD implements it with an internal
API that does not include Unix signals and Bionic doesn't implement
thread cancellation at all. Their wrapper functions are harmless.
The rest do use Unix signals to implement thread cancellations (called
SIGCANCEL everywhere except OpenBSD, where it's SIGTHR). Therefore, they
all block the application attempts to mask this signal or change its
handler (if they're not buggy). FreeBSD's and MUSL's do some locking in
their implementations[1][2] we really want to bypass, therefore we must
bypass their sigaction() wrappers.
The investigation also showed that the glibc[3] and NetBSD[4] abort()
implementations to be slightly unsafe, but we don't use them
ourselves. We're also adding QProcess::failChildProcessModifier() so
users won't have to resort to abort().
[1] https://github.com/bminor/musl/blob/master/src/signal/sigaction.c
[2] https://github.com/freebsd/freebsd-src/blob/main/lib/libthr/thread/thr_sig.c
[3] https://codebrowser.dev/glibc/glibc/stdlib/abort.c.html
[4] https://github.com/NetBSD/src/blob/trunk/lib/libc/stdlib/abort.c
Task-number: QTBUG-113822
Change-Id: I9201d9ecf52f4146bb04fffd17651123800e15a4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit e71c226d6f188abd811b28d3cb7529343f52d61f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When cross compiling for Android, these need to be marked with
[[maybe_unused]] as they might break the build due to Android not having
pthread cancellation feature.
Pick-to: 6.5
Change-Id: I3b3fb58b5e6df8ce37c2d8d9b1b8e8295f0aebb0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The same arguments that applied to the regular process-starting code in
commit e1a787a76ed462e4ed49db78a40c6d7e272182d7 (6.4) apply here too.
Task-number: QTBUG-104493
Change-Id: Icfe44ecf285a480fafe4fffd174da1b05d0054bc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
The CI is failing running all the startDetached() tests, despite this
passing on my machine (both macOS 12 and 13). We don't know why it's
happening, so we just disable use of vfork(). This doesn't affect the
regular startProcess() because forkfd() requires full fork() in OSes
without pidfd or pdfork, but it does prevent changing startDetached()
behavior, starting with the next commit.
Change-Id: Ib5ce7a497e034ebabb2cfffd1761d91c456f20e0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Commit 29b2fe40dc778ec73da7e5643fcfd8979d8ecebc disabled it by reverting
commit d6bf71123d3ef073f25610345cb5dc920e4fb783. We now add the promised
flag to opt-in. The flag is added to all Unix systems, but it really
only applies to Linux right now.
No ChangeLog because the whole UnixProcessParameters structure is new
and has its own changelog.
Task-number: QTBUG-104493
Task-number: QTBUG-111243
Task-number: QTBUG-111964
Change-Id: Icfe44ecf285a480fafe4fffd174d4effd3382495
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This commit adds those three flags that are either frequent enough or
difficult to do: close all file descriptors above stderr and reset the
signal handlers. Setting SIGPIPE to be ignored isn't critical, but is
required when the ResetSignalHandlers flag is used, as this is run
after the user child process modifier.
[ChangeLog][QtCore][QProcess] Added setUnixProcessParameters() function
that can be used to modify certain settings of the child process,
without the need to provide a callback using setChildProcessModifier().
Change-Id: Icfe44ecf285a480fafe4fffd174d0d1d63840403
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Do this by making the actual child-execution code common between
startProcess() and startDetached(). It does mean we've moved the chdir()
operation from the child to the grandchild process, though.
[ChangeLog][QtCore][QProcess] The modifier function set with
setChildProcessModifier() will now also be executed when the process is
started with startDetached().
Change-Id: Icfe44ecf285a480fafe4fffd174d9aa57dd7dfff
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There are two types of stack unwinding that can happen on Unix systems:
C++ exceptions and PThread cancellations (on some systems, like Linux,
PThread cancellations can be caught in catch(...) statements). We call a
variety of PThread cancellation functions from inside the child stub,
like close(). To avoid problems, we disable PThread cancellations
completely before fork() or vfork().
The C++ exception case is simpler, because we can be sure of catching
them with the catch (...) statement and simply transform them into an
error message. This is also testable, which the PThread cancellation
isn't.
The error message isn't ideal because we're string-frozen. I'll improve
it for 6.6.
Pick-to: 6.5
Change-Id: Icfe44ecf285a480fafe4fffd174d97a475c93ff1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This means we have more system calls (2 more in the parent), but we
can now detect non-existent or inaccessible directories before fork().
Pick-to: 6.5
Change-Id: Icfe44ecf285a480fafe4fffd174d1003581bff59
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Qt 5 and earlier versions used to share this member with Windows, where
we needed to store a pointer. We had the Q_PID public type, which was
removed in commit b73d5a0511bed8c3ccc504e74c52a61d4d3749b4 (6.0). That
commit made the QProcess::processId() public API use qint64, which is
fine. But we don't need to store more bits than the OS actually
requires.
This further reduces QProcessPrivate's size to 688 bytes on 64-bit Unix,
with 5 bytes of tail padding.
Pick-to: 6.5
Change-Id: Icfe44ecf285a480fafe4fffd174d3fa9345872c0
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This reverts commit d6bf71123d3ef073f25610345cb5dc920e4fb783 and the
docs from commit 82b75570f099911076ad0e144927862e8e359fbd
("QProcess/Linux: fix file descriptor leak in case of failed child
start").
Despite the title of the commit being reverted, the actual consequence
is slightly different: we always use the forkfd() function, but we
change whether we force the use of the fork() library function by use of
the FFD_USE_FORK flag.
Commit 97645478de3ceffce11f58eab140c4c775e48be5 (5.15) first added the
FFD_USE_FORK flag with a hack to detect whether the setupChild() virtual
might have been overwritten. A configure-time feature to force the flag
was added in commit 2ed99ff5ca338ac02f71c347b1449d4662e6c221 (6.0).
Before the 6.0 release, commit d6bf71123d3ef073f25610345cb5dc920e4fb783
removed the conditional use of FFD_USE_FORK, with the changelog message
saying "pthread_atfork() callbacks are consistently not invoked".
We've also since added vfork()-like behavior. We tried it for Qt 5.15
and reverted shortly afterwards because we had got the memory semantics
wrong. Commit e1a787a76ed462e4ed49db78a40c6d7e272182d7 (6.5) finally got
it right, for Linux, which revealed another set of problems with
functions used in the child process modifier.
Therefore, we're going to make vfork() and clone() usage opt-in if the
child process modifier is active. This commit is the first part:
disabling their use by default. The flag to opt in will come in Qt 6.6.
[ChangeLog][QtCore][QProcess] Reverted a change from Qt 6.0 that made
the childProcessModifier() callback be run in a child created by means
other than a real fork() library call, a situation in which certain
other library functions would be unusable, unreliable, or cause
deadlocks. A flag to opt in to the solution with better performance will
be added to Qt 6.6.
Task-number: QTBUG-104493
Fixes: QTBUG-111243
Fixes: QTBUG-111964
Pick-to: 6.5
Change-Id: Icfe44ecf285a480fafe4fffd174d3e66843e5a29
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reduce the number of #ifdef blocks and use quint8 for the enums that
don't need more than 8 bits anyway (none of them do). Plus move the
std::function callback to an indirect block, as most users of QProcess
won't set them and this type is 4 pointers with libstdc++ and libc++.
After this, QProcessPrivate on 64-bit Unix is 688 bytes, of which:
- 392 bytes from QIODevicePrivate
- 295 bytes of own data
- 3x56 bytes per Channel (which have 5 bytes of tail padding each)
- 1 byte of tail padding and no middle padding
Pick-to: 6.5
Change-Id: Icfe44ecf285a480fafe4fffd174d188a0821d060
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It was only used to later set exitStatus = CrashExit, so simply do it
early.
Drive-by removal of a magic numeric literal in the middle of the source
code. It's still magic, but at least we avoid accidentally making typos.
Pick-to: 6.5
Change-Id: Icfe44ecf285a480fafe4fffd174d4176a5d87641
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
ioctl call for FIONREAD takes an int arg, it won't work correctly
otherwise. Cast the return of the read() call to int, because it won't
read more than buffSize (which is an int).
Change-Id: I130202a732684257bbb0e79c9358b60a61010c46
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I got tired of being told off by the inanity 'bot for faithfully
reflecting existing #if-ery in new #if-ery. Retain only the
documentation and definition of the deprecated define.
Change-Id: I47f47b76bd239a360f27ae5afe593dfad8746538
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If the child failed to start, execChild() would (unnecessarily) store -1
in childStartedPipe[1] after writing the failure message to it and
closing that pipe. This had worked for the previous 20 years of QProcess
existence, because that was run in the child process. However, with 6.5
commit e1a787a76ed462e4ed49db78a40c6d7e272182d7 (cherry-picked to 6.4)
we implemented vfork-like behavior, meaning the child would share memory
with the parent and ran before the parent, so startProcess() failed to
close it:
// parent
// close the ends we don't use and make all pipes non-blocking
qt_safe_close(childStartedPipe[1]);
Also updated the docs to account for the fact that this is a vfork()
environment and, moreover, not using the vfork() function from glibc on
Linux.
[ChangeLog][QtCore][QProcess] Fixed a file descriptor leak in QProcess
when running on Linux 5.4 or later, if the executable being run failed
to start (for example, the file for the executable didn't exist).
Pick-to: 6.4.3 6.4 6.5
Task-number: QTBUG-111243
Change-Id: I7f354474adce419ca6c2fffd17481002e4853cc3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
fork() works by implementing Copy-On-Write for all pages that either the
parent or the child process write to. So if the parent process continues
running while the child is between fork(2) and execve(2), then it will
keep causing page faults and requiring the OS to duplicate those pages,
which may be expensive (page table updates, TLB flushes, etc.). This
problem is aggravated if the parent process is multithreaded, as the
simple act of running in the parent will cause those threads' stacks to
cause page faults.
The BSD solution for that was vfork(), which has two differences in
behavior: (1) it blocks the parent from running and (2) it shares memory
with it. But it's always been tricky, so POSIX.1-2001 deprecated it and
2008 removed its definition completely. Still, it is available somewhat
widely, and on Linux that can be achieved with clone(2) and the
CLONE_VFORK and CLONE_VM flags, for those two behaviors respectively.
Because of (2), we can't return from the forkfd() function in the child
(as that would trash the stack in the parent process), so to implement
this functionality vforkfd() adds a callback of the same signature as
glibc's clone(2) wrapper (something that hadn't occurred to me when we
attempted to use CLONE_VFORK last time).
On Linux, (1) is no problem, as clone(2) has native forkfd support. But
on other OSes, forkfd() requires the parent to run before the child
execve()s, in order to save the child PID in the list of children we're
going to handle SIGCHLD for in a non-racy way. Investigating if it is
possible to use vfork() anyway is left as an exercise for the reader.
Matching OpenDCDiag pull request:
https://github.com/opendcdiag/opendcdiag/pull/94
Pick-to: 6.4
Fixes: QTBUG-104493
Change-Id: Id0fb9ab0089845ee8843fffd16fa63c7c6f7dd1c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The forkfd_pidfd is a Linux feature, but we ended up disabling the
equivalent functionality on FreeBSD.
Pick-to: 6.3 6.4
Change-Id: I6d3880c7d99d4fc494c8fffd16fabfbc38865f94
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
It expands to the first available of
- constinit (C++20)
- [[clang::require_constant_initialization]] (Clang)
- __constinit (GCC >= 10)
Use it around the code (on and near static QBasicAtomic; this patch
makes no attempt to find all statics in qtbase).
[ChangeLog][QtCore][QtGlobal] Added macro Q_CONSTINIT.
Fixes: QTBUG-100484
Change-Id: I11e0363a7acb3464476859d12ec7f94319d82be7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
As a drive-by, did also minor refactorings/improvements.
Task-number: QTBUG-98434
Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Unless "." (or the empty string) is in $PATH, we're not supposed to find
executables in the current directory. This is how the Unix shells behave
and we match their behavior. It's also the behavior Qt had prior to 5.9
(commit 28666d167aa8e602c0bea25ebc4d51b55005db13). On Windows, searching
the current directory is the norm, so we keep that behavior.
This commit does not add an explicit check for an empty return from
QStandardPaths::findExecutable(). Instead, we allow that empty string to
go all the way to execve(2), which will fail with ENOENT. We could catch
it early, before fork(2), but why add code for the error case?
See https://kde.org/info/security/advisory-20220131-1.txt
[ChangeLog][Important Behavior Changes] When passed a simple program
name with no slashes, QProcess on Unix systems will now only search the
current directory if "." is one of the entries in the PATH environment
variable. This bug fix restores the behavior QProcess had before Qt 5.9.
If launching an executable in the directory set by setWorkingDirectory()
or inherited from the parent is intended, pass a program name starting
with "./". For more information and best practices about finding an
executable, see QProcess' documentation.
Pick-to: 5.15 6.2 6.3
Change-Id: I54f205f6b7314351b078fffd16cf7013c97ee9fb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
PIPE_BUF is optional in POSIX, e.g. "where the corresponding value is
equal to or greater than the stated minimum, but where the value can
vary depending on the file to which it is applied." [1]
GNU/Hurd does not provide PIPE_BUF, so fallback to its minimum
acceptable value, that is _POSIX_PIPE_BUF.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
Also, explicitly include <limits.h> in this file, to make sure PIPE_BUF
or _POSIX_PIPE_BUF are available without relying on other headers to
pull <limits.h>.
Change-Id: Ifae964db81841e1d31fc09e73b45594af9a326d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Several QIODevice subclasses use the qt_prettyDebug() function to get
a printable representation of the buffer data for debug output.
Rather than having this feature statically implemented in each
respective file, this patch introduces a generic function in the
QtDebugUtils namespace. Accordingly, some inaccuracies in the
use-cases have been corrected.
Change-Id: I1a8465cab08c8acf5fdcdba5085182511b1cbb7b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
qprocess_unix.cpp:633:55: error: ‘i’ was not declared in this scope
Change-Id: I152fbd9df6e9d3f31e2c2c8b23a3c1ab87aa237a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of having so much manual pointer manipulation and duplicated
code.
Change-Id: Ic90d8429a0eb4837971dfffd1664f8f63753440a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This harmonizes the execution between start() and startDetached(). Both
did QStandardDirs::findExecutable(), but duplicated code. However, only
start() supported launching .app bundles on Mac.
[ChangeLog][QtCore][QProcess] startDetached() now supports launching
.app executable bundles on macOS / iOS systems, like start() already
did.
Change-Id: Ic90d8429a0eb4837971dfffd1664f776b2c0edfd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
We haven't used the spawn functionality on QNX since Qt 5.7 (commit
005a8bfbf0022f03dafafcf2b5c438ccf0675a49) because that's when we dropped
support for QNX 6.5.0.
Change-Id: Ic90d8429a0eb4837971dfffd1664f9712bdce2d8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Use a structure that will automatically close them for us. This doesn't
apply to startProcess() because the pipes there are long-lived (though
each of them in QProcessPrivate could be an AutoPipe...).
The destructor only runs in the parent process, so the child processes
don't need to worry about setting file descriptors to -1.
Pick-to: 6.1
Change-Id: Ic90d8429a0eb4837971dfffd1664ed98f3d74d1c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This is unnecessary because we can only get SIGPIPE if the reading end
of the pipe is closed. And that can only happen if the parent process
has exited, meaning there's no one to read our message anyway.
Change-Id: Ic90d8429a0eb4837971dfffd1664ec6821993ada
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This should have been SIG_DFL, as we're about to execute a child
process. It's the child's responsibility to ignore SIGPIPE if it wants
to, or get killed by it when it writes to an pipe with no readers.
Qt itself does this for its own purposes (see qt_ignore_sigpipe() [until
I can get some time to teach Linux about O_NOSIGPIPE]). Therefore, we
ought to reset what we've done.
Change-Id: Ic90d8429a0eb4837971dfffd166585a686790dde
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
And set *pid to -1.
[ChangeLog][QtCore][QProcess] If a startDetached() fails to start the
target application, the QProcess object should now have a proper error
string in errorString().
Pick-to: 6.1
Change-Id: Ic90d8429a0eb4837971dfffd1664e825ffcb923e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
That qWarning cannot be in the child process (we don't know if a user
logger is fork-no-exec-safe) and the failure to chdir() should be
reported as a failure in QProcess::startDetached() instead.
Change-Id: Ic90d8429a0eb4837971dfffd1664e7577c81610b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: David Llewellyn-Jones <david.llewellyn-jones@jolla.com>
That only created an opportunity for qWarning(), which should never be
in the child process in the first place.
Change-Id: Ic90d8429a0eb4837971dfffd1664e57a2291ea78
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: David Llewellyn-Jones <david.llewellyn-jones@jolla.com>
