Files
qt-creator/tests/auto/utils/process/processtestapp/processtestapp.h

110 lines
3.6 KiB
C
Raw Normal View History

// Copyright (C) 2022 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
#include <functional>
#include <utils/commandline.h>
#include <utils/environment.h>
#include <utils/qtcassert.h>
QT_BEGIN_NAMESPACE
class QProcess;
QT_END_NAMESPACE
namespace Utils { class Process; }
#define SUB_PROCESS(SubProcessClass)\
class SubProcessClass\
{\
public:\
static const char *envVar() { return m_envVar; }\
private:\
SubProcessClass() { registerSubProcess(envVar(), &SubProcessClass::main); }\
~SubProcessClass() { unregisterSubProcess(envVar()); }\
static int main();\
static constexpr char m_envVar[] = "TST_QTC_PROCESS_" QTC_ASSERT_STRINGIFY(SubProcessClass);\
friend class ProcessTestApp;\
};\
\
SubProcessClass m_ ## SubProcessClass
class ProcessTestApp
{
public:
using SubProcessMain = std::function<int ()>;
static void invokeSubProcess();
// Many tests inside tst_Process need to start a new subprocess with custom code.
// In order to simplify things we produce just one separate executable - processtestapp.
// We embed all our custom subprocesses in processtestapp and enclose them in separate
// classes. We select desired process to run by setting the relevant environment variable.
// Test classes are defined by the SUB_PROCESS macro. The macro defines a class
// alongside of the corresponding environment variable which is set prior to the execution
// of the subprocess. The following subprocess classes are defined:
SUB_PROCESS(SimpleTest);
SUB_PROCESS(ChannelEchoer);
SUB_PROCESS(ExitCode);
SUB_PROCESS(RunBlockingStdOut);
SUB_PROCESS(LineCallback);
SUB_PROCESS(StandardOutputAndErrorWriter);
SUB_PROCESS(ChannelForwarding);
SUB_PROCESS(BlockingProcess);
SUB_PROCESS(Crash);
SUB_PROCESS(CrashAfterOneSecond);
SUB_PROCESS(RecursiveCrashingProcess);
QtcProcess: Fix terminate() for process launcher ProcessLauncherImpl::terminate() was behaving the same as ProcessLauncherImpl::kill() in case of process launcher implementation - in both cases the launcher immediately returned confirmation about receiving the close request and was putting the corresponding process into its reaper. However, the issue with this approach is that we can't receive anymore any potential ready read signal from the process being terminated after a call to terminate(). The fix is to diverge the behavior of terminate() and kill() of ProcessLauncherImpl. The behavior of kill() remains the same, while terminate() just instructs the process launcher to start termination without putting the process into the reaper, yet. Add a test that checks for any possible zombies. We run the RecursiveBlockingProcess recursively. The most nested process blocks. After a short wait we terminate the outermost process. With this test we are trying to see if terminating the middle process terminates also its children and doesn't leave zombies. Before we execute the test (and also by the end of this test) we call Singleton::deleteAll() in order to ensure that reaping of previously running processes has finished. We ensure the number of running processtestapps is zero. Later, we ensure that the leaf process was already started and the number of running processtestapps equals the depth of recursion. Fix apparent bug in getLocalProcessesUsingProc(). Change-Id: I7e2bc46ad5ca22f26620da86fbaf0fa00a7db3c3 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-01 15:14:05 +02:00
SUB_PROCESS(RecursiveBlockingProcess);
// In order to get a value associated with the certain subprocess use SubProcessClass::envVar().
// The classes above define different custom executables. Inside invokeSubProcess(), called
// by processtestapp, we are detecting if one of these variables is set and invoke a respective
// custom executable code directly. The exit code of the process is reported to the caller
// by the return value of SubProcessClass::main().
private:
ProcessTestApp();
static void registerSubProcess(const char *envVar, const SubProcessMain &main);
static void unregisterSubProcess(const char *envVar);
};
class SubProcessConfig
{
public:
SubProcessConfig(const char *envVar, const QString &envVal);
void setupSubProcess(Utils::Process *subProcess) const;
void setupSubProcess(QProcess *subProcess) const;
static void setPathToProcessTestApp(const QString &path);
private:
const Utils::Environment m_environment;
};
static const char s_runBlockingStdOutSubProcessMagicWord[] = "42";
// Expect ending lines detected at '|':
static const char s_lineCallbackData[] =
"This is the first line\r\n|"
"Here comes the second one\r\n|"
"And a line without LF\n|"
"Rebasing (1/10)\r| <delay> Rebasing (2/10)\r| <delay> ...\r\n|"
"And no end";
static const char s_outputData[] = "This is the output message.";
static const char s_errorData[] = "This is the error message.";
enum class BlockType {
EndlessLoop,
InfiniteSleep,
MutexDeadlock,
EventLoop
};
static const int s_crashCode = 123;
QtcProcess: Fix terminate() for process launcher ProcessLauncherImpl::terminate() was behaving the same as ProcessLauncherImpl::kill() in case of process launcher implementation - in both cases the launcher immediately returned confirmation about receiving the close request and was putting the corresponding process into its reaper. However, the issue with this approach is that we can't receive anymore any potential ready read signal from the process being terminated after a call to terminate(). The fix is to diverge the behavior of terminate() and kill() of ProcessLauncherImpl. The behavior of kill() remains the same, while terminate() just instructs the process launcher to start termination without putting the process into the reaper, yet. Add a test that checks for any possible zombies. We run the RecursiveBlockingProcess recursively. The most nested process blocks. After a short wait we terminate the outermost process. With this test we are trying to see if terminating the middle process terminates also its children and doesn't leave zombies. Before we execute the test (and also by the end of this test) we call Singleton::deleteAll() in order to ensure that reaping of previously running processes has finished. We ensure the number of running processtestapps is zero. Later, we ensure that the leaf process was already started and the number of running processtestapps equals the depth of recursion. Fix apparent bug in getLocalProcessesUsingProc(). Change-Id: I7e2bc46ad5ca22f26620da86fbaf0fa00a7db3c3 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-01 15:14:05 +02:00
static const char s_leafProcessStarted[] = "Leaf process started";
static const char s_leafProcessTerminated[] = "Leaf process terminated";
Q_DECLARE_METATYPE(BlockType)