[PATCH] autobuild: Stop waf uninstall from removing test_tmpdir

Martin Schwenke martin at meltin.net
Mon Mar 20 09:25:53 UTC 2017


Hi Metze,

On Mon, 20 Mar 2017 09:53:08 +0100, Stefan Metzmacher <metze at samba.org>
wrote:

> >> waf uninstall (via BuildContext.install() in Build.py) removes empty
> >> directories all the way up the directory tree.  This means that it
> >> removes test_tmpdir and any empty directories above it.  
> 
> How did you find that?

A lot of patience...  :-)

1. Ran private autobuilds, bisecting the list of default tasks in in
   autobuild.py.

   There's arguably a bug in autobuild.py where it uses a fixed random
   sleep of 1s even if you specify multiple tasks on the command-line.
   We can look at that later.  :-)

   I was able to exclude the big Samba builds and tests quite quickly.

   I finally got down to semi-reliably recreating with only ctdb and
   replace in the list.

2. Couldn't recreate with just ctdb, so went back to ctdb and replace.

   When I did this I hacked CTDB's "make autotest" to only run the
   first test, where it always failed.  That sped things up.  :-)

3. Noticed that the failure was completely reliable when I hacked the
   limits to random-sleep.sh to match the random sleeps in a
   particular failed autobuild. So it became clear that it would fail
   when replace finished before ctdb started.

4. Ran a private autobuild for just replace and confirmed that the tmp
   directory was gone when it completed.

5. Instrumented the replace task in autobuild.py to check if the tmp
   directory still existed after each sub-task.

   Noticed that it was gone after distcheck.

6. Instrumented distcheck() and found the problem was in the recursive
   waf invocation.

7. Split out the uninstall part of the recursive waf invocation, since
   that seemed the most likely suspect.  Confirmed.

8. Looked at BuildContext.install() in Build.py, was amazed and finally
   instrumented the directory removal loop in there to confirm.

   The directory removal loop probably deserves a "break" to optimise
   it.

That was some pretty "big hammer" debugging and it took a while...
but satisfying to track down the culprit. :-)

peace & happiness,
martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170320/173158ad/attachment.sig>


More information about the samba-technical mailing list