Endianness issues with systemd <-> dbus communication

Fridrich Strba fridrich.strba at suse.com
Thu Mar 13 05:12:35 PDT 2014

Hash: SHA1

Hello, good people,

On 12/03/14 14:14, Simon McVittie wrote:
> From the code you quoted, it seems sd_bus correctly distinguishes 
> between those two two header fields (at least in that snippet -
> there might be a bug elsewhere).

There is some news on this front. It seems that the culprit are the
hashmap functions, which are used to store and retrieve the
reply_callback structures of asynchronous calls. They take a uint64_t
pointer for the key argument. Nevertheless, the reply_cookie of the
sd_bus_message is stored in a 32bit variable.

This works by a sheer luck on x86-64:
- - it's little endian, and
- - the struct is padded to the next 8 byte boundary because
reply_cookie is between two pointers.

s390x being a 64-bit big endian, this fails, resulting in complete
failure of any communication between systemd and the dbus-daemon. It
never gets past the initial Hello handshake, sent as an asynchronous

We are currently looking into a proper solution, since simply changing
that variable to uint64_t fixes some stuff, but breaks things elsewhere.

This means that the problem is most likely not on the dbus-daemon
side. For solution, I will keep you posted.

Thanks a lot for hand-holding


Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the dbus mailing list