[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Updating the test suite (Was: commit: ldap/tests run.in)



Hallvard B Furuseth wrote:
--- scripts/test021-certificate 29 Sep 2005 20:26:44 -0000 1.14
+++ scripts/test021-certificate 30 Sep 2005 05:32:50 -0000 1.15
echo "Starting slapd on TCP/IP port $PORT1..."
+#valgrind -v --gdb-attach=yes --logfile=info --num-callers=16 --leak-check=yes --leak-resolution=high $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING </dev/tty > $LOG1 2>&1 &
$SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 &

_That's_ what I do too. Edit the test suite to invoke some program.
Though I put the program and args in an env variable.
BTW, was that 'time' call intended to reach CVS?

(Oops) No. It does no harm though.

I guess it would be nice to fix things so we don't have to edit the scripts and mess up our commits, but how do you set up the variables in a script that invokes slapd (or any program) multiple times, and you only want special treatment for one specific invocation?

Actually that --soft argument to my Demand_RC() causes a lot of problems
when I look at it closely. For the time being I think this would at most
implement that 'run all' does not abort if one test fails.

I still have to think about how it would get used. After a fresh build, you should not ignore any errors by default. An option like this will only be used after you've hit one error and you want to move on to the following tests. As such, I think a more relevant solution will be to allow telling "all" to begin at test XX and advance from there. Perhaps another option to say all, but excluding XX, YY, and ZZ because we already know they will fail.
Yes. The excessive sleeps here were getting annoying. I don't know
about waiting for up to 30 or more seconds; if the server doesn't
start up right away it probably isn't going to start up at all. Even
on the slowest dev system I used (an OS/390 beast) it usually started
within 10 seconds.

I agree - with the caveat that it gets a lot slower with valgrind --memcheck on an already slow box. I remember _some_ sleep was too fast for me in that case, but I don't remember if it was this one. Anyway, we could reduce the default sleep time but take the max sleep time from an optional environment variable.

I would guess the sleeps in the replication tests (to allow propagation) should get this variable treatment. The default sleeps are more than long enough right now, and they would need to be stretched further for a valgrind case.
to find the test I want. Then after completing the test name I have to
go back and delete "scripts/" after writing the test name. That's three
extra keystrokes - horrible! (As opposed to - how many? - in this part
of the discussion?:-)

OK. Does no harm...
Kill_named () {
eval "fV_name=\${fV_PIDNAME$1-child} fV_PID$1="
echo "Stopping and waiting for $fV_name."
kill -HUP $1 && wait $1 && return 0
echo "$fV_name (pid $1) failed ($?)!" >&2
Kill_all
return 99
}
This function must unset the particular PID from fv_PIDVARS, otherwise
Kill_all will complain.

It does, indirectly. For pid 345, Fv_PIDVARS contains '$fV_PID345', where fV_PID345 originally is '345'. Kill_named sets fV_PID345=''.

OK.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/