As ptest-runner communicates with child processes via pipe2(),
the corresponding channels are not attached to a pty. In that
situation stdio facilities like printf() or fwrite() are fully
buffered. If a ptest would use them, without bothering
to fflush() the output, ptest-runner will only receive what
was written by the child ptest process after a buffer gets filled.
If the unit tests are proceeding slowly, this may mean that
ptest-runner will erroneously timeout due to an apparent lack of
'signs of life' from the child process.
stdbuf utility from coreutils adjusts the buffering to a line-buffered
one, and so ptest-runner will get the lines as soon as they are
written.
Signed-off-by: Alexander Kanavin <alex.kana...@gmail.com>
---
utils.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/utils.c b/utils.c
index 504df0b..c130fbd 100644
--- a/utils.c
+++ b/utils.c
@@ -243,16 +243,13 @@ filter_ptests(struct ptest_list *head, char **ptests, int
ptest_num)
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
- char **argv = malloc(sizeof(char) * 2);
+ char* argv[] = {"stdbuf", "-oL", "-eL", "./run-ptest", NULL};
chdir(dirname(strdup(run_ptest)));
- argv[0] = run_ptest;
- argv[1] = NULL;
-
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
- execv(run_ptest, argv);
+ execvp(argv[0], argv);
exit(1);
}
@@ -291,12 +288,12 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
if (pfds[0].revents != 0) {
while ((n = read(fds[0], buf,
WAIT_CHILD_BUF_MAX_SIZE)) > 0)
- fwrite(buf, n, 1, fps[0]);
+ fwrite(buf, n, 1, fps[0]);
fwrite("hallo", 5 ,1 ,fps[0]); fflush(fps[0]);
}
if (pfds[1].revents != 0) {
while ((n = read(fds[1], buf,
WAIT_CHILD_BUF_MAX_SIZE)) > 0)
- fwrite(buf, n, 1, fps[1]);
+ fwrite(buf, n, 1, fps[1]);
fwrite("hallo-err", 9 ,1 ,fps[0]); fflush(fps[1]);
}
clock_gettime(clock, &sentinel);
--
2.17.1
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
