This is a pyzmq bug
What pyzmq version?
24.0.1
What libzmq version?
4.3.4
Python version (and how it was installed)
3.9.19 (a2113ea87262, Apr 21 2024, 05:40:24) [PyPy 7.3.16 with GCC 10.2.1 20210130 (Red Hat 10.2.1-11)]
OS
RHEL 9.1 (running in a docker container)
What happened?
When running the following minimal example under valgrind (and publish data to that socket from a different container), I sometimes get an "invalid read" error, which I think corresponds to the close(linger=0) followed by garbage collection of the socket (which under pypy happens at an arbitrary time) and re-opening a new socket
Code to reproduce bug
import zmq
def create_sockets(zmq_context):
socket = zmq_context.socket(zmq.SUB)
socket.SUBSCRIBE = ""
socket.connect("tcp://containername:45678")
return socket
def main():
print("START")
zmq_context = zmq.Context()
while True:
socket = create_sockets(zmq_context)
print("socket created")
for i in range(30):
socket.recv_multipart()
print("Going to reconnect the socket")
socket.close(linger=0)
if __name__ == '__main__':
main()
Traceback, if applicable
# valgrind output
==00:00:03:12.699 177== Thread 3:
==00:00:03:12.699 177== Invalid read of size 4
==00:00:03:12.699 177== at 0xA0F00AB: zmq::signaler_t::send() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0DC4DF: zmq::object_t::send_term_ack(zmq::own_t*) (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0DF2D7: zmq::own_t::check_term_acks() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0EFC04: zmq::session_base_t::pipe_terminated(zmq::pipe_t*) (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0E0939: zmq::pipe_t::process_pipe_term_ack() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0D06D3: zmq::io_thread_t::in_event() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0CEB7B: zmq::epoll_t::loop() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA104AF8: thread_routine (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0x81D12E9: start_thread (in /usr/lib64/libc.so.6)
==00:00:03:12.699 177== by 0x82555E3: clone (in /usr/lib64/libc.so.6)
==00:00:03:12.699 177== Address 0xbfa6960 is 112 bytes inside a block of size 176 free'd
==00:00:03:12.699 177== at 0x484A6DF: operator delete(void*) (vg_replace_malloc.c:1131)
==00:00:03:12.699 177== by 0xA0F4ED5: zmq::socket_base_t::~socket_base_t() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA101858: zmq::sub_t::~sub_t() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0CEB7B: zmq::epoll_t::loop() (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA104AF8: thread_routine (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0x81D12E9: start_thread (in /usr/lib64/libc.so.6)
==00:00:03:12.699 177== by 0x82555E3: clone (in /usr/lib64/libc.so.6)
==00:00:03:12.699 177== Block was alloc'd at
==00:00:03:12.699 177== at 0x4847ACF: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:607)
==00:00:03:12.699 177== by 0xA0F2069: zmq::socket_base_t::socket_base_t(zmq::ctx_t*, unsigned int, int, bool) (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA1129AF: zmq::xsub_t::xsub_t(zmq::ctx_t*, unsigned int, int) (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA1019E8: zmq::sub_t::sub_t(zmq::ctx_t*, unsigned int, int) (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0F1A96: zmq::socket_base_t::create(int, zmq::ctx_t*, unsigned int, int) (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0xA0C291E: zmq::ctx_t::create_socket(int) (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/pypy3.9/site-packages/zmq/libzmq.pypy39-pp73-x86_64-linux-gnu.so)
==00:00:03:12.699 177== by 0x8360E2B: ffi_call_unix64 (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/libffi.so.6)
==00:00:03:12.699 177== by 0x8360754: ffi_call (in /usr/lib64/pypy3.9-v7.3.16-linux64/lib/libffi.so.6)
==00:00:03:12.699 177== by 0x596D42A: pypy_g_ccall_ffi_call__ffi_cifPtr_arrayPtr_arrayPtr_arr (in /usr/lib64/pypy3.9-v7.3.16-linux64/bin/libpypy3.9-c.so)
==00:00:03:12.699 177== by 0x69B6A20: pypy_g_jit_ffi_call (in /usr/lib64/pypy3.9-v7.3.16-linux64/bin/libpypy3.9-c.so)
==00:00:03:12.699 177== by 0x5DE4A47: pypy_g_W_CTypeFunc__call (in /usr/lib64/pypy3.9-v7.3.16-linux64/bin/libpypy3.9-c.so)
==00:00:03:12.699 177== by 0x5B5F2FA: pypy_g_BuiltinCode_funcrun_obj (in /usr/lib64/pypy3.9-v7.3.16-linux64/bin/libpypy3.9-c.so)
More info
No response
This is a pyzmq bug
What pyzmq version?
24.0.1
What libzmq version?
4.3.4
Python version (and how it was installed)
3.9.19 (a2113ea87262, Apr 21 2024, 05:40:24) [PyPy 7.3.16 with GCC 10.2.1 20210130 (Red Hat 10.2.1-11)]
OS
RHEL 9.1 (running in a docker container)
What happened?
When running the following minimal example under valgrind (and publish data to that socket from a different container), I sometimes get an "invalid read" error, which I think corresponds to the
close(linger=0)followed by garbage collection of the socket (which under pypy happens at an arbitrary time) and re-opening a new socketCode to reproduce bug
Traceback, if applicable
More info
No response