[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/