GitLab

To reproduce: Build dbus 1.12.x on a FreeBSD 12.1 x86_64 virtual machine, with --enable-embedded-tests, --enable-modular-tests, and GLib installed. I was doing this to see whether FreeBSD is affected by the regression #304 (closed) caused by fixing #294 (closed) (that is, whether it behaves like Solaris in this respect), and if yes, whether !165 (merged) would fix it.

Expected result: The test case test_odd_limit in test/fdpass.c asserts that if we set the limit for maximum number of fds in a message to 7, and then try to send messages with 6, 7, 8 and 9 fds in, the result is that the senders of 6 or 7 fds succeed, while the senders of 8 or 9 fds get disconnected by the dbus-daemon. It should pass.

The limit is used to allocate space for out-of-band message headers (cmsg) with enough space for 7 fds.

Actual result: In at least one case (I think it's /odd-limit/at, which sends 7 fds), we get a D-Bus message with no fds attached to it. It might be the special Disconnected message that we get when disconnected, or it might be the message we expected to receive but with its fds removed - I can't immediately tell from the test's output.

I am not going to debug this myself, but *BSD users who would like dbus fd-passing to be more reliable on their platform are invited to help. (I have no idea whether other BSDs like NetBSD, OpenBSD, Dragonfly are affected; I would guess that they are somewhat likely to be, because fd-passing is quite old and the various BSDs probably share a lot of its implementation.)

fd limits that are odd numbers might be reasonably be considered pathological. Real dbus deployments probably use an even number, and are unaffected by this.