Using a Context closed by a copy raises Bad address instead of RuntimeError

[mrkn]

With pyzmq 22.1.0, the following script occurs zmq.error.ZMQError: Bad address.

import zmq
import copy

ctx = zmq.Context()
ctx2 = copy.copy(ctx)
ctx2.term()
ctx.get(zmq.IO_THREADS)

The execution results is below:

$ python term_copy.py
Traceback (most recent call last):
  File "term_copy.py", line 7, in <module>
    ctx.get(zmq.IO_THREADS)
  File "zmq/backend/cython/context.pyx", line 157, in zmq.backend.cython.context.Context.get
  File "zmq/backend/cython/checkrc.pxd", line 28, in zmq.backend.cython.checkrc._check_rc
zmq.error.ZMQError: Bad address

The reason why this error is the following:

• ctx and `ctx2 have the same context handle
• ctx2.term() closes the handle, but it does not tell it toctx
• ctx.get(...) uses the closed handle, and it occurs Bad Address

I guess term method should check _shadow property, but the current implementation does not. There is the same issue in Socket.close method.

I tried to write a patch but I couldn't decide whether we should allow shadow objects term/close their handles. Because Context.__del__ does not call term when the object is a shadow. I guess several options can be considered to fix term method. For example, the explicit call of term for a shadow object closes its handle and tells to the original object. The other option is that the explicit call of term for a shadow object occurs an error. I couldn't select options because I don't know the implementation policy of this library.

[minrk]

Thanks for finding this!

I tried to write a patch but I couldn't decide whether we should allow shadow objects term/close their handles.

Yes, they absolutely should be allowed, but they shouldn't do it automatically on __del__, etc. I think that's already the case, though.

So the only issue here is that arguably the wrong error is raised, but an error should still be raised. You would expect pyzmq's RuntimeError: Context has been destroyed, but instead you are getting zmq's own version of the same error (ZMQError: Bad address). But there are no cases where there are errors in calls that should succeed, if I understand.

Possibly, the best thing to do is to catch EFAULT and set the _closed property, to handle any possible mechanism by which the underlying context could have been closed. I don't know if it's possible for this error to occur for other reasons, though - we might need to check a specific call for EFAULT to make it safe, e.g. getting context.IO_THREADS or socket.TYPE. I'm not sure how tedious / expensive that would be, though.