Thread: regression script/makefile exit failure
I have seen several cases where either pg_regress appears not to exit with the expected non-zero exit status or "make check" does not apparently exit with the expected non-zero status. In particular, I've seen it on cygwin, windows, and have at least a suspicion of it happening on FreeBSD. The apparently offending code is this: message "initializing database system" [ "$debug" = yes ] && initdb_options='--debug' "$bindir/initdb" -D "$PGDATA"-L "$datadir" --noclean $initdb_options >"$LOGDIR/initdb.log" 2>&1 if [ $? -ne 0 ] then echo echo "$me: initdb failed" echo "Examine $LOGDIR/initdb.log for the reason." echo (exit 2); exit fi and it's called from this makefile target: check: all -rm -rf ./testtablespace mkdir ./testtablespace $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule --multibyte=$(MULTIBYTE) $(MAXCONNOPT) The practical consequence of this is that instead of failing at this stage, the buildfarm script continues on until it somewhat inexplicably fails at the initdb stage. Now, perhaps I'm calling it wrong, but I don't think so. The relevant perl code is this: my @makeout = `cd $pgsql/src/test/regress && $make check 2>&1`; my $status = $? >>8; which idiom seems to work as expected everywhere else quite happily. And in fact I've seen "make check" fail as expected on other failure paths (such as not matching the expected result.) Anyone have any penetrating thoughts? cheers andrew
Further investigation has shown that the exit/trap idiom used in pg_regress.sh is less than 100% portable. The following shell script has been seen to produce incorrect output on both Cygwin and FreeBSD: #!/bin/sh trap ' st=$? echo status = $st exit $st ' 0 (exit 9); exit I'm not sure how we get a portable solution (other than maybe converting the shell script to perl). cheers andrew I wrote: > > I have seen several cases where either pg_regress appears not to exit > with the expected non-zero exit status or "make check" does not > apparently exit with the expected non-zero status. > > In particular, I've seen it on cygwin, windows, and have at least a > suspicion of it happening on FreeBSD. > > The apparently offending code is this: > > message "initializing database system" > [ "$debug" = yes ] && initdb_options='--debug' > "$bindir/initdb" -D "$PGDATA" -L "$datadir" --noclean > $initdb_options >"$LOGDIR/initdb.log" 2>&1 > > if [ $? -ne 0 ] > then > echo > echo "$me: initdb failed" > echo "Examine $LOGDIR/initdb.log for the reason." > echo > (exit 2); exit > fi > > > and it's called from this makefile target: > > check: all > -rm -rf ./testtablespace > mkdir ./testtablespace > $(SHELL) ./pg_regress --temp-install > --top-builddir=$(top_builddir) --schedule=$(srcdir)/parallel_schedule > --multibyte=$(MULTIBYTE) $(MAXCONNOPT) > > > The practical consequence of this is that instead of failing at this > stage, the buildfarm script continues on until it somewhat > inexplicably fails at the initdb stage. > > > Now, perhaps I'm calling it wrong, but I don't think so. The relevant > perl code is this: > > my @makeout = `cd $pgsql/src/test/regress && $make check 2>&1`; > my $status = $? >>8; > > which idiom seems to work as expected everywhere else quite happily. > And in fact I've seen "make check" fail as expected on other failure > paths (such as not matching the expected result.) > > > > Anyone have any penetrating thoughts? > > cheers > > andrew > > > > >
Andrew Dunstan <andrew@dunslane.net> writes:
> Further investigation has shown that the exit/trap idiom used in
> pg_regress.sh is less than 100% portable.
> The following shell script has been seen to produce incorrect output on
> both Cygwin and FreeBSD:
This is distinctly less than credible. If it were true, we'd have been
seeing regression failures on FreeBSD for years. The script has looked
like that at least back to 7.1 ...
regards, tom lane
Tom Lane said: > Andrew Dunstan <andrew@dunslane.net> writes: >> Further investigation has shown that the exit/trap idiom used in >> pg_regress.sh is less than 100% portable. >> The following shell script has been seen to produce incorrect output >> on both Cygwin and FreeBSD: > > This is distinctly less than credible. If it were true, we'd have been > seeing regression failures on FreeBSD for years. The script has looked > like that at least back to 7.1 ... > I think you possibly misunderstand. It's not that the trap handler doesn't get called - it's that it doesn't get the correct $?. The only symptom of incorrectness is that pg_regress would exit with a status of 0 rather than 2 or whatever it should be. DarcyB ran that test script for me yesterday on his FreeBSD-6 box (buildfarm's herring) and it produced "status = 0" rather than the expected "status = 9". I would not expect anyone to have noticed this behaviour unless they were testing the exit status of "make check". cheers andrew
Andrew Dunstan wrote: > Further investigation has shown that the exit/trap idiom used in > pg_regress.sh is less than 100% portable. > > The following shell script has been seen to produce incorrect output > on both Cygwin and FreeBSD: > > > #!/bin/sh > > trap ' > st=$? > echo status = $st > exit $st > ' 0 > > (exit 9); exit I seem to recall that there is a bug in the FreeBSD shell with line breaks in traps. Try changing the above to trap 'st=$?; echo status = $st; exit $st' 0 -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: >Andrew Dunstan wrote: > > >>Further investigation has shown that the exit/trap idiom used in >>pg_regress.sh is less than 100% portable. >> >>The following shell script has been seen to produce incorrect output >>on both Cygwin and FreeBSD: >> >> >>#!/bin/sh >> >>trap ' >> st=$? >> echo status = $st >> exit $st >>' 0 >> >>(exit 9); exit >> >> > >I seem to recall that there is a bug in the FreeBSD shell with line >breaks in traps. Try changing the above to > >trap 'st=$?; echo status = $st; exit $st' 0 > > Thankyou Peter! I'd never have guessed something so obscure! I have confirmed that this is the problem, and ascertained that the Cygwin shell exhibits the same behaviour. I will submit a patch for pg_regress.sh shortly (after a little testing using buildfarm). cheers andrew