On Mon, Dec 10, 2018 at 15:47:15 -0200, Eduardo Habkost wrote: > On Sun, Dec 09, 2018 at 05:27:38PM -0500, Emilio G. Cota wrote: > > On Fri, Dec 07, 2018 at 18:41:07 -0200, Eduardo Habkost wrote: > > > I've noticed QEMU Travis builds are failing recently, and they > > > seem to happen only on the --enable-gprof jobs. I have enabled > > > V=1 and noticed that the jobs are hanging inside test-qht-par. > > > > > > Example here (look for "/qht/parallel/2threads-0%updates-1s"): > > > > > > https://travis-ci.org/ehabkost/qemu-hacks/jobs/465081311 > > > > > > Does anybody have any idea why? > > > > So if I read that output correctly, it seems that the second > > test in qht-par never completes. > > > > Enabling gprof and gcov (as in that build) should just lower > > the throughput of the benchmark (test-qht-par invokes qht-bench), > [...] > > Unrelated question: is there a specific reason why test-qht-par > is written in C using gtest, instead of being just a shell script > that runs qht-bench?
I didn't know how to integrate a shell script with gtester, so I went with a C program. There's a possibility that the use of system(3) here is what's causing the problem. Can you try running the following branch on travis? https://github.com/cota/qemu/tree/test-qht-par I moved most of qht-bench into qht-bench.inc.c, so that both qht-bench.c and test-qht-par.c can use it. This gets rid of the use of system(3) in test-qht-par.c. Thanks, Emilio
