On 11 April 2017 at 16:14, Markus Armbruster wrote:
> No objection to this work-around for tests leaving crap behind, but I
> think we should also try harder not to leave crap behind. Say give each
> test its own scratch directory, make sure no test writes outside it, and
> have the harness remov
Peter Maydell writes:
> Occasionally if a test crashes or is interrupted by the user
> at the wrong moment it could leave behind a stale UNIX
> socket in /tmp/. This will then cause a subsequent test
> run to fail spuriously with
> tests/libqtest.c:70:init_socket: assertion failed (ret != -1): (
On Fri, Mar 31, 2017 at 01:36:41PM +0100, Peter Maydell wrote:
> Occasionally if a test crashes or is interrupted by the user
> at the wrong moment it could leave behind a stale UNIX
> socket in /tmp/. This will then cause a subsequent test
> run to fail spuriously with
> tests/libqtest.c:70:init_
On 03/31/2017 07:36 AM, Peter Maydell wrote:
> Occasionally if a test crashes or is interrupted by the user
> at the wrong moment it could leave behind a stale UNIX
> socket in /tmp/. This will then cause a subsequent test
> run to fail spuriously with
> tests/libqtest.c:70:init_socket: assertion
On 03/31/2017 09:36 AM, Peter Maydell wrote:
Occasionally if a test crashes or is interrupted by the user
at the wrong moment it could leave behind a stale UNIX
socket in /tmp/. This will then cause a subsequent test
run to fail spuriously with
tests/libqtest.c:70:init_socket: assertion failed (
Occasionally if a test crashes or is interrupted by the user
at the wrong moment it could leave behind a stale UNIX
socket in /tmp/. This will then cause a subsequent test
run to fail spuriously with
tests/libqtest.c:70:init_socket: assertion failed (ret != -1): (-1 != -1)
if it happens to reuse t
