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::zmqabort(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::chartraits, std::allocator >&) (sockfd=sockfd_@entry=264, ipaddr="") at src/ip.cpp:183 4 0x00007f56d2b81938 in get_peer_address(zmq::fdt) (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_pairt const&, bool) (this=0x7f55defb4de0, fd=264, options_=, endpoint_uripair=..., has_handshakestage=) 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_pairt const&) (this=0x7f55defb4de0, fd=, options_=, endpoint_uripair=) at src/zmtp_engine.cpp:74 7 0x00007f56d2b7fb04 in zmq::stream_listener_base_t::createengine(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 threadroutine(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?