Comment 8 for bug 1634989

Did a bit more reading into the root cause; seems to be that it is undefined behavior in erlang when one opens a port multiple times with the same fd. This is path that rabbitmq-server currently triggers, and in _some_ versions of erlang this segfaults.

A standalone example of the faulty code in rabbitmq-server is:

erl -noshell -eval 'Port = open_port({fd, 0, 2}, [out]), Port2 = open_port({fd, 2, 2}, [out]), port_command(Port, "a"), port_close(Port), erlang:halt(10)'

Standalone test:
Trusty: OK, Xenial: segfault Yakkety: segfault, Zesty: OK

rabbitmq-server has offending code:
Trusty: yes Xenial: yes, Yakkety: yes, Zesty: no

Note: The rabbitmq-server offending code path is essentially anything that uses the format_stderr(Fmt, Args) function helper function. The testcase provided in #1 is just a single specifc instance that could trigger the segfault. IOW, the bug is somewhat more broad of a bug than that testcase and description, thus more interesting to SRU a fix into Xenial/Yakkety.

As yakkety and xenial contain both a rabbitmq-server with the offending code && an erlang that will segfault with it, we should SRU there.

While trusty contains the offending codepath 1) it cannot be triggered with the erlang version in trusty (1.16.x) and 2) the proposed upstream commit for the fix makes claim that it is safe with changes now made erlang-17 or later, so this fix is not certain to not cause other issues on trusty. IOW, best to leave trusty alone.