When a pipe processes a delimiter and is already not in active state but still
has an unfinished message, the message is leaked.
Solution: issue a rollback before losing the reference to the pipe.
(cherry picked from commit 6815138501b9f2a69e807bc3527d93583e633233)
Conflicts:
src/pipe.cpp
Solution: check if a session's _pipe has been allocated before using
it, since as a consequence of creating the pipes after the handshake
it's no longer guaranteed to be there.
(cherry picked from commit 350b4b34f460b91b8fa8f692cf6bc30d561a5711)
Conflicts:
src/session_base.cpp
The deployment is triggered by tagging on the zeromq/libzmq repository.
Of the many builds travis is checking only the default one with
libsodium and drafts disabled is used for deployment.
For now the results of `make distcheck` are deployed as well as their
md5 and sha1 hash sums. Further changes may upload a generated
Changelog as well.
Solution: add the document files to the MAN_DOC and MAN_HTML targets
in doc/Makefile.am only if BUILD_DOC and INSTALL_MAN are set,
otherwise leave the targets empty to avoid errors in make distcheck.
Solution: add -lssp on Solaris only when libsodium is enabled and has
been found. Also disable pedantic and Werror, as libsodium headers
use pragma diagnostic which are not available in gcc 3.4.
Solution: in the Windows-specific ifdef in tcp_listener set_address,
check for error and set errno only after the IPv4 fallback has failed
too, to avoid setting errno when the socket creation succeeds through
the fallback.
Solution: if opening an IPv6 TCP socket fails because IPv6 is not
available, try to open an IPv4 socket instead when creating and
connecting a TCP endpoint.
Solution: if opening an IPv6 TCP socket fails because IPv6 is not
available, try to open an IPv4 socket instead when creating and
binding a TCP endpoint.
While sending very large messages (far beyond what fits in a the tcp
buffer, so it takes multiple sendto system calls for it to finish),
zmq_close will close the connection regardless of ZMQ_LINGER.
In case no engine is attached, a pipe->check_read() is needed to look
for the delimiter in the pipe and ultimately trigger the pipe
termination.
However, if there *is* an engine attached, the check_read() looks ahead
and finds the delimiter and terminates the connection even though the
engine might actually still be in the middle of sending a message.
This happens because while the io_thread is still busy sending the data,
the pipe can get terminated and the io thread ends up being terminated.
Solution: always initialised zmq::options_t class variables arrays to
avoid reading uninitialised data when CURVE is not yet configured and
a getsockopt ZMQ_CURVE_{SERVER | PUBLIC | SECRET]KEY is issued.
Backport from libzmq.
