Bad file descriptor while retrieving peer address

[spawar1985]

Please use this template for reporting suspected bugs or requests for help.

Bad file descriptor while accessing peer address

Kubernetes having centos image

*4.3.4 (commit hash if unreleased):

• OS: Linux(centos)

Minimal test code / Steps to reproduce the issue

1. Application is running on cloud and issue is rarely reproducible. But It generates a core dump . Call stack is as follows:

   1 0x00007f56d2339e65 in GI_abort () at abort.c:79
   2 0x00007f56d2b46804 in zmq::zmq_abort(char const*) (errmsg=errmsg@entry=0x7f56d24aebeb "Bad file descriptor") at
   src/err.cpp:88
   3 0x00007f56d2b4a947 in zmq::get_peer_ip_address(int, std::cxx11::basic_string<char, std::char_traits,
   std::allocator >&) (sockfd=sockfd@entry=264, ip_addr_="")
   at src/ip.cpp:183
   4 0x00007f56d2b81938 in get_peer_address(zmq::fd_t) (s_=264) at src/stream_engine_base.cpp:70
   5 0x00007f56d2b82983 in zmq::stream_engine_base_t::stream_engine_base_t(int, zmq::options_t const&,
   zmq::endpoint_uri_pair_t const&, bool)
   (this=0x7f55defb4de0, fd_=264, options_=, endpoint_uri_pair_=..., has_handshake_stage_=)
   at src/stream_engine_base.cpp:133
   6 0x00007f56d2b99846 in zmq::zmtp_engine_t::zmtp_engine_t(int, zmq::options_t const&, zmq::endpoint_uri_pair_t const&)
   (this=0x7f55defb4de0, fd_=, options_=, endpoint_uri_pair_=) at
   src/zmtp_engine.cpp:74
   7 0x00007f56d2b7fb04 in zmq::stream_listener_base_t::create_engine(int) (this=0x53f900, fd_=264) at
   src/stream_listener_base.cpp:110
   8 0x00007f56d2b8621e in zmq::tcp_listener_t::in_event() (this=0x53f900) at src/tcp_listener.cpp:94
   9 0x00007f56d2b45b8c in zmq::epoll_t::loop() (this=0x4ef1b0) at src/epoll.cpp:206
   10 0x00007f56d2b86bef in thread_routine(void*) (arg_=0x4ef208) at src/thread.cpp:257
   11 0x00007f56d28fe1ca in start_thread (arg=) at pthread_create.c:479
   12 0x00007f56d23518d3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

the the remote endpoint component was not available (inaccessible) at the point of crash

What's the actual result? (include assertion message & call stack if applicable)

The Irony is call stack doesn't show any of the applications function that triggered the above call stack.
So, I guess its ZMQ internal issue. If anybody has seen the similar issue in their application, they can provide more information

What's the expected result?

process should not crash

[spawar1985]

Does any one has idea about this issue?