[Pkg-utopia-maintainers] Bug#890975: dbus: test-server-oom fails on reproducible-builds infrastructure: org.freedesktop.DBus.Error.AddressInUse

[Simon McVittie]

Source: dbus
Version: 1.12.4-1
Severity: normal

The 4th of 4 test cases in test/internals/server-oom is failing on the
reproducible-builds infrastructure, causing FTBFS, due to the unexpected
error org.freedesktop.DBus.Error.AddressInUse:

**
ERROR:../../../test/internals/server-oom.c:78:test_new_tcp: assertion failed (error.name == DBUS_ERROR_NO_MEMORY): ("org.freedesktop.DBus.Error.AddressInUse" == "org.freedesktop.DBus.Error.NoMemory")
../../../build-aux/tap-driver.sh: line 639: 28655 Aborted                 "$@"
# random seed: R02S603b8549a89b53876cf9b1988c4b3759
1..4
# Start of server tests
ok 1 /server/new-tcp
PASS: test-server-oom 1 /server/new-tcp
ok 2 /server/new-nonce-tcp
PASS: test-server-oom 2 /server/new-nonce-tcp
ok 3 /server/new-tcp-star
PASS: test-server-oom 3 /server/new-tcp-star
# ERROR:../../../test/internals/server-oom.c:78:test_new_tcp: assertion failed (error.name == DBUS_ERROR_NO_MEMORY): ("org.freedesktop.DBus.Error.AddressInUse" == "org.freedesktop.DBus.Error.NoMemory")
ERROR: test-server-oom - too few tests run (expected 4, got 3)
ERROR: test-server-oom - exited with status 134 (terminated by signal 6?)

(DBUS_ERROR_NO_MEMORY is allowed here because the point of this test is
to simulate malloc() returning NULL.)

This does not seem to happen on production buildds or in my local
testing. I don't know what's different about the reproducible-builds
workers.

The failing test is /server/new-tcp-v4, and the failure mode is that
_dbus_server_new_for_tcp_socket ("localhost", "localhost", "0", "ipv4",
&error, FALSE) fails with the given error. That means that approximately
this call sequence failed, when done repeatedly:

getaddrinfo ("localhost", "0",
             {ai_family=AF_INET, ai_protocol=IPPROTO_TCP,
              ai_socktype=SOCK_STREAM, ai_flags=AI_ADDRCONFIG | AI_PASSIVE},
             &ai);
fd = socket (ai->ai_family, SOCK_STREAM, 0);
setsockopt (fd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one));
setsockopt (fd, IPPROTO_TCP, TCP_NODELAY, &one, sizeof(one));
bind (fd, ai->ai_addr, ai->ai_addrlen);

Possibly the reproducible builds worker has only a few transient TCP ports
available and so runs out sooner than a production buildd? I would have
expected SO_REUSEADDR to mitigate this, but perhaps it doesn't?

Not setting a release-critical severity since I've never seen this failure
mode outside the reproducible builds infrastructure.

    smcv