[MERGE] Delete faulty test that can leak a subprocess and/or hang the test suite.

[Martin Pool]

Martin Pool has voted resubmit.
Status is now: Resubmit
Comment:
As John says, the two tests are not actually redundant.

If you do want to disable it I'd rather you leave it there marked as 
xfail unreliable rather than deleting it.

This kind of thing is a bit difficult to test, because it has 
concurrency as well as bzr running as a subprocess, and because this 
kind of debugging function is not nicely reentrant.  As it happened, Bob 
had a failure in this test the other day -- but it was actually showing 
a bug (though not a bug in breakin.)

If you have a zombie process then that tells you the parent didn't wait 
on it yet, which may help isolate the failure.

Overall I have mixed feelings, so I'm going to just say resubmit, but 
it's a kind of soft resubmit

* breakin is unlikely to be broken by other changes, and fairly isolated 
to fix if you do go to use it and discover it's not working, so having 
it untested is not all that bad

* that said cheating by letting things be untested does tend to come 
back and bite you

* we know this test has sometimes found real problems but also has 
sometimes broken spuriously

I would guess that on a busy but multi-core machine one of two things 
are happening:

Some extra output is being sent out, like a warning about deprecated 
modules, and that's throwing the timing off.

.5 seconds is not enough time for it to start.

So I'd add an assertion about the message we get, and then also increase 
the delays.

For details, see: 
http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2vdq5mmrq.fsf%40free.fr%3E
Project: Bazaar