[DTrace-devel] [PATCH] test: ensure child processes are running for tst.manypids.sh

[Eugene Loh]

(Sorry for the funny formatting.  I copied from the archive since this 
never showed up in my inbox.)

I get the rationale for this, but I'm unable to prove to myself that the 
change makes a difference.  The main problem is that I cannot routinely 
reproduce the problem.  So I'm curious how your testing went.  How 
reproducible are the fails without the patch? How reproducible are the 
passes with the patch?

I tried stressing things.  E.g., bumping up from 100 to 200 pids. Or, 
cutting down to 1, 2, 3, or 4 pids.  (That should make the DTrace script 
start up faster, improving its chances of catching a pid off guard.)  No 
luck.

Also, the few times I've seen this test fail in previous runs, the pid 
probe that was called out was one of the very first ones... perhaps the 
first one.  That corresponds to the pid that would have had the longest 
opportunity to start up.

In all, if you have robust testing that shows fails without this patch 
and passes with this patch, I'm all for it.  In the absence of my own 
data in that regard, I'm not confident that this patch attacks the problem.

8< 8< 8< 8< 8<

The tst.manypids.sh test depends on a large amount of child processes
running, and tracing them all.  However, there seems to be a small chance
that one of the child processes isn't completely started by the time the
probes are being created, causing dtrace to fail enabling all probes.

Adding a 1s delay after the child processes are started to give them time
to start completely (i.e. complete the clone and exec using the preload
library).

Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>

diff --git a/test/unittest/pid/tst.manypids.sh 
b/test/unittest/pid/tst.manypids.sh
@@ -33,6 +33,8 @@ while [ "$i" -lt "$numkids" ]; do
      let i=i+1
  done

+sleep 1
+
  export LD_PRELOAD=

  let i=0